Blog Marcin Kalmus

Dopuszczalne formaty plików przy komunikacji elektronicznej w Pzp

2020-08-17 – Marcin Kalmus komentarze (0)

Uprawnienia zamawiającego do ograniczenia przyjmowanych formatów plików



Choć elektronizacja w zamówieniach publicznych zagościła już na dobre, to cały czas wywołuje jeszcze wątpliwości i kontrowersje. Ostatnimi czasy przez różne fora internetowe poświęcone Pzp, przetoczyło się kilka burzliwych dyskusji dotyczących dopuszczalnych formatów plików, w jakich mogą być przyjmowane dokumenty elektroniczne składane w toku postępowania. W niniejszym wpisie postaram się usystematyzować wiedzę na ten temat.

Ramy prawne

Zgodnie z art. 10g pkt 2 Pzp Prezes Rady Ministrów zobowiązany został do określenia, w drodze rozporządzenia sposobu sporządzania i przechowywania dokumentów elektronicznych oraz sposobu i trybu ich przekazywania, udostępniania i usuwania.

Obowiązek ten zrealizowany został poprzez wydanie w dn. 27 czerwca 2017 r. Rozporządzenia Prezesa Rady Ministrów w sprawie użycia środków komunikacji elektronicznej w postępowaniu o udzielenie zamówienia publicznego oraz udostępniania i przechowywania dokumentów elektronicznych  (Dz.U. 2017 poz. 1320 z późn. zm. – dalej jako „Rozporządzenie ŚKE”)
W akcie tym nie znajdziemy wprost odpowiedzi na pytanie, jakie formaty dokumentów elektronicznych są dopuszczalne. § 4 Rozporządzenia ŚKE odsyła nas w tym zakresie do kolejnych aktów prawnych tj. do przepisów wykonawczych wydanych na podstawie art. 18 ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne [przepisy te zwarte są w Rozporządzeniu Rady Ministrów w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (tj. Dz.U. 2017 poz. 2247 – dalej jako „Rozporządzenie KRI”)]:

„§ 4. Dokumenty elektroniczne przekazywane za pośrednictwem środków komunikacji elektronicznej, o których mowa w § 2 ust. 1, są sporządzane w jednym z formatów danych określonych w przepisach wydanych na podstawie art. 18 ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne.”

 

Sposób redakcji tego przepisu jest podstawą sporów i niejasności - w dyskusjach na forach internetowych dało się wyodrębnić dwa główne stanowiska.

 

Zwolennicy pierwszego z poglądów, fragment „są sporządzane w jednym z formatów danych” odczytują jako uprawnienie dla Zamawiającego do określenia jednego dopuszczalnego w danym postępowaniu formatu danych. Zazwyczaj jest nim format PDF. W Wyroku z dnia 2019-08-09, KIO 1467/19  Krajowa Izba Odwoławcza zajęła stanowisko zdające się warunkowo potwierdzać taką interpretację. Zastrzegła jednakże, że postanowienia SIWZ dopuszczające wyłącznie format PDF przez Odwołującego nie zostały zakwestionowane i jako takie stały się dla stron w tym postępowaniu wiążące:


Na podstawie przekazanych przez zamawiającego akt sprawy Izba ustaliła, że zgodnie z postanowieniami SIWZ odnoszącymi się do sposobu sporządzenia oferty zamawiający zastrzegł, że winna być ona sporządzona w formacie danych pdf. Nie ulega wątpliwości, że jest to jeden z formatów wymienionych do stosowania w załączniku nr 2 do rozporządzenia o interoperacyjności dla plików tekstowych. Zamawiający nie uczynił zatem w dokumentacji przetargowej zastrzeżenia, które pozostawałoby w sprzeczności z powszechnie obowiązującymi przepisami. Kluczowym dla niniejszej sprawy jest fakt, że odwołujący przyjął do wiadomości zapisy SIWZ i ani ich nie kwestionował na etapie poprzedzającym składanie ofert, ani też nawet nie zadawał pytań dotyczących tej kwestii. Należy zatem uznać, że zastrzeżenie takie zaakceptował. Obecnie odwołujący powołuje się na przepisy powszechnie obowiązujące stwierdzając, że stosowanie plików w formacie .xml na potrzeby postępowania o udzielenie zamówienia jest w pełni dopuszczalne. W ocenie Izby taki wniosek jest nieuprawniony, biorąc pod uwagę zapisy SIWZ. Zauważyć należy, że zamawiający wskazał w treści SIWZ jakie formaty zostały przez niego dopuszczone wymieniając te, które umożliwiają otwarcie ofert przy wykorzystaniu oprogramowania które on posiada. Każdy format, dopuszczony przepisami będzie zatem właściwym w tym przypadku, jedynym ograniczeniem jest zastrzeżenie, że nie może to być taki format, który nie został wymieniony w załączniku nr 2 do rozporządzenia o interoperacyjności.
Biorąc zatem pod uwagę fakt, że zamawiający w SIWZ określił w jakim formacie winna być sporządzona oferta, a odwołujący przesłał plik w innym formacie, jako profesjonalista winien liczyć się z tym, że jego oferta nie będzie mogła zostać odczytana w sposób poprawny na sprzęcie zamawiającego. Nie jest bowiem tak, jak twierdzi odwołujący, że skoro złożył ofertę w jednym z formatów wymienionych w rozporządzeniu o interoperacyjności to "nie może ponosić negatywnych konsekwencji związanych z brakiem możliwości otwarcia tejże oferty, albowiem jest to okoliczność za którą odwołujący nie odpowiada i która odwołującego nie dotyczy". Umknęło uwadze odwołującego, że zamawiający w SIWZ wskazał w jakim formacie ofertę należy złożyć i chociaż nie zakazał stosowania formatu .xml, to jednak w żadnym miejscu SIWZ go nie dopuścił. W istocie zatem stało się tak, że plik przesłany przez odwołującego jako oferta chociaż został zdeszyfrowany, to jednak nie mógł zostać otwarty przy wykorzystaniu posiadanego przez zamawiającego oprogramowania. Izba ustaliła to na podstawie załączonych do akt sprawy zrzutów z ekranu, prezentujących próby, jakich dokonywał zamawiający chcąc otworzyć plik przesłany przez odwołującego."

Zwolennicy drugiego z poglądów (do których i ja należę) fragment „są sporządzane w jednym z formatów danych” odczytują w ten sposób, że Wykonawca przygotowując dokument elektroniczny, powinien zdecydować się i wybrać jeden z dopuszczonych formatów. W każdym razie Zamawiający nie jest uprawniony do ograniczania ilości formatów wyłącznie do jednego. Za stanowiskiem takim przemawia kilka ważnych argumentów.


Po pierwsze — adresatem przepisu jest podmiot sporządzający dany dokument elektroniczny, a nie podmiot, który taki dokument będzie przyjmował.


Po drugie
do podmiotów przyjmujących pliki (dokumenty elektroniczne), skierowany jest § 18 ust. 2 Rozporządzenia KRI, który stanowi, że jeżeli z przepisów szczegółowych albo opublikowanych w repozytorium interoperacyjności schematów XML lub innych wzorów nie wynika inaczej (a w zakresie dokumentów elektronicznych na gruncie Pzp nie wynika (z pewnymi wyjątkami, ale o tym poniżej przy okazji plików xml)), podmioty realizujące zadania publiczne umożliwiają przyjmowanie dokumentów elektronicznych służących do załatwiania spraw należących do zakresu ich działania w formatach danych określonych w załącznikach nr 2 i 3 do rozporządzenia.

Przepis ten w mojej ocenie należy odczytywać jako obowiązek, w miarę możliwości  technicznych i organizacyjnych, zapewnienia przyjmowania wszystkich dopuszczonych rodzajów plików.

Czy obowiązek przyjmowania wszystkich formatów plików wymienionych w Załącznikach do Rozporządzenia KRI jest bezwzględny?

Na tak postawione pytanie odpowiedź w mojej ocenie musi być negatywna. Obowiązek ten nie ma charakteru bezwzględnego – gdzie zatem wyznaczyć granicę dopuszczalnych formatów?

Wydaje się, że zakres dopuszczonych formatów danych powinien być jak najszerszy, tak by realizowane były podstawowe cele wprowadzenia powyższych regulacji, a wnikające wprost z art. 10g Pzp. Przepisy wykonawcze, oraz sposób ich stosowania:

  • nie mogą wpływać na uczciwą konkurencję pomiędzy wykonawcami — wykonawcy wszak dysponują różnym oprogramowaniem i sprzętem komputerowym,
  • muszą zapewniać sprawność postępowania o udzielenie zamówienia — zamawiający i wykonawcy nie mogą być „zmuszani” do używania sprzętu i oprogramowania, którym nie dysponują lub którego w prosty i bezpłatny sposób nie mogą pozyskać (z zastrzeżeniem np. art. 10d Pzp),
  • nie mogą ograniczać otwartego dostępu wykonawców do postępowania o udzielenie zamówienia — w szczególności Zamawiający nie powinien zamieszczać na stronie internetowej skanów dokumentów, gdyż może stać to w sprzeczności z postanowieniami ustawy z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (Dz.U. 2019 poz. 848). Oprogramowanie do odczytywania zawartości stron internetowych przeznaczone dla osób z dysfunkcjami wzroku ma kłopot z odczytaniem skanu dokumentu (jego obrazu), natomiast świetnie radzi sobie z dokumentami i treściami tekstowymi. Dla przykładu skan wzoru umowy zapisany do pliku PDF będzie dla takiego oprogramowania nieczytelny, ale już PDF utworzony bezpośrednio z edytowalnego dokumentu Word nie sprawia problemów z odczytaniem treści.
  • powinny zapewniać bezpieczeństwo przetwarzanych danych.

Jakie formaty plików można zatem ograniczyć

Generalną  w mojej opinii zasadą, jest dopuszczenie wszystkich powszechnie stosowanych formatów plików, a wszelkie ograniczenia winny być obiektywnie uzasadnione. Np. dopuszczenie tylko plików w formacie .doc (plik pakietu Microsoft Office) na pewno uczciwą konkurencję naruszy. Zainstalowanie na komputerach alternatywnego otwartoźródłowego i darmowego pakietu biurowego np. Libre Office obsługującego format .odt nie wydaje się działaniem, z którym Zamawiający nie jest sobie w stanie poradzić – wystarczy wszak email do służb informatycznych z prośbą o instalację takiego oprogramowania. Stanowisko takie zaprezentował również Urząd Zamówień Publicznych. W opinii „Przykładowe zapisy siwz - elektroniczny jedz” możemy przeczytać między innymi:


"a) Zamawiający dopuszcza w szczególności następujący format przesyłanych danych: .pdf, .doc, .docx, .rtf,.xps, .odt.[ 2]

[2]: Zamawiający określając dopuszczalne formaty danych w jakich może zostać przedłożony dokument JEDZ korzysta z katalogu formatów wskazanych w załączniku nr 2 do Rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych. Należy pamiętać, że wybór określonych formatów danych nie może prowadzić do naruszenia zasad uczciwej konkurencji i równego traktowania wykonawców i jednocześnie musi umożliwiać użycie kwalifikowanego podpisu elektronicznego.]

Pliki tekstowe i tekstowo-graficzne

Zgodnie z art. 9 ust. 1 Pzp Postępowanie o udzielenie zamówienia, z zastrzeżeniem wyjątków określonych w ustawie, prowadzi się z zachowaniem formy pisemnej – czyli na pewno powinniśmy dopuścić pliki tekstowe* takie jak pliki z rozszerzeniami .txt; .rtf; .odt; .doc; docx. Powinniśmy dopuścić również formaty plików umożliwiających przekazywanie treści tekstowo-graficznych takich jak - .pdf; .xps; .odp; .ppt; pptx; jpg; .tif; .png oraz plików arkuszy kalkulacyjnych: .ods; xls; xlsx


* prezentowany podział opracowałem wyłącznie na potrzeby niniejszego artykułu na podstawie właściwości użytkowych poszczególnych rodzajów plików i prezentuje w nim najczęściej występujące typy plików. Podział ten jest odmienny od przyjętego w Załączniku nr 2 do Rozporządzenia KRI. Np. Załącznik ten, jako pliki tekstowo-graficzne definiuje wyłącznie pliki .pdf i .xps. Ja zakwalifikowałem jednak do nich również pliki prezentacji multimedialnych i pliki zawierające grafikę — np. do formatu .jpg możemy zapisać zeskanowaną referencję, której oryginałem dysponujemy wyłącznie w formie pisemnej, a z takiego pliku graficznego treść referencji będzie można również bez problemu odczytać.

Wszystkie ww. typy plików moim zdaniem powinny być dopuszczone – oczywiście Zamawiający w dokumentacji przetargowej może wskazać format preferowany, ale zobowiązany będzie przyjąć również pliki w pozostałych formatach. Bo dlaczego np. zamawiający miałby nie przyjąć oferty w formacie pliku prezentacji multimedialnej, w której każda strona będzie kolejnym „slajdem”, a plik zostanie podpisany kwalifikowanym podpisem elektronicznym? Dopóki Zamawiający jest w stanie zapoznać się z treścią takiej oferty, to ja żadnych przeciwwskazań nie widzę.

Pliki XML - dlaczego pliki xml występują w zamówieniach publicznych?

Powodem jest uniwersalność formatu XML (może być rozpoznawany niezależnie od platformy sprzętowej, czy też posiadanego oprogramowania), a także umożliwia wykorzystywanie i wymianę danych przez różne systemy informatyczne. W konsekwencji ustanowiono ten format jako obowiązujący dla dokumentów wytwarzanych publicznie - § 2 ust. 3 Rozporządzenia Ministra Spraw Wewnętrznych i Administracji z dnia 30 października 2006 r. w sprawie niezbędnych elementów struktury dokumentów elektronicznych (wydane na podstawie art. 5 ust. 2a ustawy z dnia 14 lipca 1983 r. o narodowym zasobie archiwalnym i archiwach).

„3. Dokumenty elektroniczne przygotowane do przesyłania za pomocą środków komunikacji elektronicznej sporządza się w formacie XML.”

Poniżej fragment kodu xml pierwszych zdań niniejszego wpisu otworzony w notatniku (format tekstowy):

w:rsidRDefault="00BB797F" w:rsidP="00305601"><w:r><w:t xml:space="preserve">Choć elektronizacja w zamówieniach publicznych zagościła już na dobre, to cały czas wywołuje jeszcze wątpliwości i kontrowersje. Ostatnimi czasy przez różne fora internetowe poświęcone </w:t></w:r><w:proofErr w:type="spellStart"/><w:r><w:t>Pzp</w:t></w:r><w:proofErr w:type="spellEnd"/><w:r><w:t xml:space="preserve">,


Jak widzicie, da się z niego „wyłuskać” treść, ale łatwe i czytelne na pewno to nie jest. Dla chcących więcej się dowiedzieć o języku XML polecam artykuł „XML dla niewtajemniczonych” opublikowany na stronie Microsoftu.

Do prawidłowego wyświetlenia dokumentu XML niezędny jest dedykowany "wizualizator" który potrafi nadać tekstowi odpowiednie formatowanie, czy też czytelny układ graficzny. Z uwagi na powyższe, Zamawiający może ograniczyć np. format oferty, czy przygotowanych przez siebie wzorów wykazów / oświadczeń do plików tekstowych i tekstowo graficznych, wyłączając tym samym dla takich dokumentów format XML. Uzasadnieniem jest tu brak możliwości „odczytania” takiego pliku bez odpowiedniej aplikacji do wizualizacji. Cytowany powyżej Wyrok KIO 1467/19 potwierdza takie stanowisko.

Zupełnie inaczej sprawa się będzie przedstawiała dla dokumentów, dla których istnieją ogólnodostępne aplikacje / systemy umożliwiające ich wizualizację, takich jak np.:

Dla powyższych dokumentów podstawy do ograniczenia ich składania w formacie XML nie znajduję. Zamawiający otrzymując plik XML, jest w stanie bez trudności zapoznać się z jego treścią.

Pliki skompresowane

Załącznik nr 2 do Rozporządzenia KRI, jako formaty plików skompresowanych wskazuje .zip; . tar; .gz (.gzip); i 7Z. Należy pamiętać, że kompresji można poddawać zarówno poszczególne pliki, jak i całe foldery zawierające pliki różnych typów.
W mojej ocenie w tym zakresie Zamawiający powinien dopuścić wszystkie z ww. formatów. Znakomita większość aplikacji potrafi obsłużyć do odczytu wszystkie typy plików skompresowanych. Instalacja darmowego oprogramowania nie powinna stanowić tu przeszkody dla Zamawiającego.

W Rozporządzeniu KRI nie znajdziemy dośc popularnego formatu kompresji danych RAR. Format ten jest formatem komercyjnym, co znaczy że  do "spakowania" pliku niezbędny jest płatny program. Czy zatem Zamawiający nie może dopuścić takiego formatu? W mojej ocenie może. Po pierwsze - błedęm byłoby wymaganie wyłacznie takiego formatu kompresji, ale dopuszczenie go jako jednego z wielu jest dla wykonawców ułatwieniem (zwłaszcza dla tych którzy już komercyjną wersję oprogramowania nabyli). Po drugie - choć samo oprogramowanie do kompresji jest płatne, to już aplikacje pozwalające na "rozpakowanie" są dla Zamawiającego darmowe. Np. popularny i udostępniany na licencji open source program 7ZIP doskonale sobie z formatem RAR radzi.

Podpisy kwalifikowane

W zakresie dopuszczonych rodzajów i formatów podpisów kwalifikowanych ewentualną podstawą do ograniczenia możemy odnaleźć w Rozporządzeniu Parlamentu Europejskiego i Rady (UE) NR 910/2014 z dnia 23 lipca 2014 r. w sprawie identyfikacji elektronicznej i usług zaufania w odniesieniu do transakcji elektronicznych na rynku wewnętrznym oraz uchylające dyrektywę 1999/93/WE, otóż motyw 32 stanowi:

„W zakresie, w jakim niniejsze rozporządzenie tworzy obowiązek uznania usługi zaufania, taka usługa zaufania może nie zostać uznana wyłącznie wtedy, gdy adresat tego obowiązku nie może jej odczytać lub zweryfikować z powodów technicznych będących poza bezpośrednią kontrolą tego adresata. Jednak obowiązek ten nie powinien sam w sobie nakładać na organ publiczny wymogu uzyskania sprzętu i oprogramowania niezbędnych do zapewnienia technicznej możliwości odczytania wszystkich istniejących usług zaufania.

Ograniczenia wynikać mogą zatem jedynie ze stosowanego przez Zamawiającego oprogramowania do weryfikacji podpisów. Zamawiający powinien wskazać w SIWZ, w jaki sposób i przy użyciu jakich aplikacji weryfikował będzie podpisy kwalifikowane. Dobrze byłoby też wskazać formaty podpisów obsługiwanych przez stosowane aplikacje. Opis taki pozwoli wykonawcy na samodzielną weryfikację plików, w sposób taki, w jaki będzie to potem czynił zamawiający – na pewno przyczyni się to do zminimalizowania błędów związanych z niepodpisanymi lub niewłaściwie podpisanymi plikami. Np. jeśli Zamawiający korzystał będzie z kwalifikowanej usługi walidacji udostępnionej przez SzuKIO.pl, to obsługuje ona następujące formaty podpisów elektronicznych:

  • XMLsig
  • XAdES
  • PAdES
  • CAdES
  • ASIC

Niedopuszczalne jest też zawężanie formatów podpisów np. Zamawiający, nie jest w żadnym wypadku uprawniony do ograniczenia podpisywania plików PDF wyłącznie formatem Pades (podpis wewnętrzny dedykowany wyłącznie plikom pdf). Jeśli Zamawiający otrzyma plik PDF podpisany podpisem zewnętrznym Xades (lub okalającym) nie może w mojej ocenie, takiego pliku nie uznać jako prawodłowo podpisany.

 

Podsumowanie

Zamawiający:

  • przygotuj sprzęt komputerowy i oprogramowanie umożliwiające odczytanie jak największej ilości formatów plików (konieczność instalacji dodatkowego oprogramowania nie jest wystarczającym uzasadnieniem do zawężenia formatów plików, o ile jest ono powszechnie dostępne)
  • wskaż w dokumentach zamówienia (najczęściej SIWZ) jakie formaty plików będą akceptowane – dla różnych dokumentów możesz wskazać różne formaty plików
  • opisz oprogramowanie które będziesz wykorzystywał do weryfikacji kwalifikowanych podpisów elektronicznych

Wykonawco:

  • analizując treść udostępnionej dokumentacji zamówienia zwróć uwagę, czy zamawiający w sposób nieuprawniony nie ograniczył dopuszczalnych formatów plików - jeśli nie zanegujesz takich postanowień (wniosek o zmianę SIWZ / odwołanie) to mogą one stać się w danym postępowaniu wiążące. Jeżeli złożysz ofertę nie stosując się do nich, może ona zostać odrzucona!  

Ciekawy wyrok związany z konsekwencjami używania przez Wykonawcę i Zamawiającego różnych platform - w tym wypadku MacOS i Windows

Wyrok Krajowej Izby Odwoławczej z dnia 2019-10-15, KIO 695/19

"Tym samym Izba uznała, iż plik zawierający gwarancję bankową nr CRD/G/0083567 z dnia 16 stycznia 2019 r. wystawiony przez gwaranta, czyli bank, jest tożsamy z plikiem zawierającym gwarancję bankową, stanowiącą wadium zabezpieczające ofertę odwołującego, jaki został pobrany przez zamawiającego po upływie terminu składania ofert w postępowaniu. Natomiast wadliwość pliku gwarancji wadialnej, a właściwie niemożność zweryfikowania kwalifikowanego podpisu elektronicznego złożonego na tej gwarancji, która została pobrana przez zamawiającego, wynikała z przyczyn technologicznych, których odwołujący nie mógł przewidzieć szczególnie, że zamawiający nie podał informacji co do tego z jakiego oprogramowania będzie korzystał przy badaniu ofert i dokumentów złożonych przez wykonawców oraz do jakich konsekwencji może doprowadzić posługiwanie się przez wykonawców oprogramowaniem systemowym pochodzącym od innego producenta niż to posiadane przez zamawiającego. Przy czym, mając na uwadze ustalenia biegłego można pokusić się o stwierdzenie, że zarówno zamawiający jak i odwołujący działając w dobrej wierze i z należytą starannością nie muszą zakładać a priori wszelkich możliwych trudności jakie mogą się pojawiać w obrocie dokumentami funkcjonującymi w postaci elektronicznej, przez co trudno wymagać, aby spodziewali się podanej przez biegłego przyczyny sporu jaki zawisł między nimi w przedmiotowej sprawie, gdyż w ocenie Izby zapobieżenie tej przyczynie wymagało wysoko wyspecjalizowanej wiedzy technicznej, a została ona stwierdzona dopiero po dopuszczeniu przez Izbę środka dowodowego z opinii biegłego.

Izba uznała argumentację przedstawioną przez biegłego w opinii, która sprowadzała się w skrócie do stwierdzenia, że podczas pobierania pliku z miniPortalu i zapisaniu go przez zamawiającego, który pracował w środowisku windowsowym, doszło do tego, iż znaki LF końca linii używane przy stosowaniu oprogramowania MacOS zostały przekształcone w znaki CR LF końca linii używane w oprogramowaniu Windows, wobec tego zmienił się rozmiar pliku (o 25 bajtów - 25 linii LF - CR LF) i finalnie kwalifikowany podpis elektroniczny nie zweryfikował się poprawnie. Powyższe ustalenia nie były kwestionowane przez strony, zatem tym bardziej Izba nie znalazła podstaw do tego, aby nie wziąć ich pod uwagę zważywszy, że biegły właśnie po to został powołany, aby swoją wiedzą specjalistyczną z dziedziny informatyki dać odpowiedź umożliwiającą rozpoznanie sprawy.

Warto przy tym dodać, że zamawiający podkreślał doniosłe znaczenie podpisu, w tym wypadku kwalifikowanego podpisu elektronicznego dla możliwości wyegzekwowania gwarancji. Izba ma świadomość tej kwestii, niemniej w przedmiotowej sprawie uznała, że obawy zamawiającego są bezpodstawne.

Po pierwsze, jak wykazano i wskazano powyżej, oba pliki dotyczące gwarancji są tożsame, tj. plik stanowiący gwarancję bankową wystawiony przez bank i przekazany odwołującemu, na którym kwalifikowany podpis elektroniczny został poprawnie zweryfikowany jest tożsamy z plikiem stanowiącym gwarancję wadialną pobraną przez zamawiającego z miniPortalu, na którym kwalifikowany podpis elektroniczny nie został poprawnie zweryfikowany. W tym miejscu należy podkreślić, że biegły w opinii stwierdził, że pomimo negatywnej weryfikacji podpisu na gwarancji pobranej z miniPortalu w dalszym ciągu było możliwe odczytanie tożsamości nadawcy z jego certyfikatu zapisanego w binarnej strukturze podpisu pdf, a także było możliwe odczytanie treści danych również zapisanych w binarnej strukturze podpisu pdf.

Po drugie, należy zwrócić uwagę na aneks nr 1 z dnia 18 lutego 2019 r. do gwarancji bankowej nr CRD/G/0083567 z dnia 16 stycznia 2019 r., który także został dołączony do oferty odwołującego i był w posiadaniu zamawiającego. Przedmiotowy aneks przedłużał termin ważności ww. gwarancji do dnia 30 kwietnia 2019 r. Zawiera przy tym informację, iż pozostałe warunki ww. gwarancji nie ulegają zmianie i co najważniejsze został podpisany kwalifikowanym podpisem elektronicznym, który został poprawnie zweryfikowany. W związku z tym gdyby gwarancja wadialna nie była ważna, to nie byłoby możliwości zawarcia do niej przedmiotowego aneksu.

Mając powyższe na uwadze należy uznać, że wadium zostało wniesione przez odwołującego w sposób prawidłowy tym samym zamawiający naruszył treść art. 89 ust. 1 pkt 7b) Pzp, przez odrzucenie oferty odwołującego na podstawie tego przepisu."

Dyskusja:

Ten wpis nie ma jeszcze komentarza. Masz coś do dodania, pytanie albo chcesz po prostu wyrazić swoją opinię? Śmiało :)

Anonim. Zaloguj się aby się podpisać.

Nie znasz SzuKIO?

Przetestuj działanie SzuKIO.

Jeżeli korzystasz z wersji bezpłatnej lub nie masz jeszcze konta:

Sprawdź DEMO.

Marcin Kalmus

Marcin Kalmus

Konsultant ds. zamówień publicznych, moderator i ekspert SzuKIO.pl

Praktyk, posiadający od 2006 r. doświadczenie w udzielaniu zamówień klasycznych oraz sektorowych, specjalizujący się w elektronicznych trybach udzielania zamówień. Członek Ogólnopolskiego Stowarzyszenia Konsultantów Zamówień Publicznych.

Kontakt: marcin.kalmus @ szukio.pl lub 793 991 891

Nie znasz SzuKIO?

Przetestuj działanie SzuKIO.

Jeżeli korzystasz z wersji bezpłatnej lub nie masz jeszcze konta:

Sprawdź DEMO.

Nowości na blogu:

Projekt ustawy o zmianie ustawy o umowie koncesji na roboty budowlane lub usługi, ustawy ‒ Prawo zamówień publicznych oraz ustawy ‒ Przepisy wprowadzające ustawę ‒ Prawo zamówień publicznych

Nowe PZP jeszcze nie weszło w życie, a już będzie nowelizowane! 2020-07-27 » Marcin Kalmus

Nowe Pzp - projekt Rozporządzenia w sprawie planu postępowań 2020-07-26 » Marcin Kalmus

Wzory ogłoszeń do nowego PZP dla zamówień poniżej progów unijnych 2020-07-24 » Marcin Kalmus

Tarcza 4.0 - Koniec publikacji ogłoszeń w siedzibie Zamawiającego i inne zmiany 2020-06-25 » Marcin Kalmus

Czy środki na rachunku VAT potwierdzają zdolność finansową wykonawcy? 2020-06-24 » Marcin Kalmus

Polecane

Elektroniczne oferty w postępowaniach o wartości nie przekraczającej "progu unijnego" 2020-04-03 » Martyna Lubieniecka / Marcin Kalmus