Do obowiązków komórki należy osadzenie w repozytorium wytworzonych przez komórkę poprawnych dokumentów elektronicznych wraz z powiązanymi metadanymi akt wychodzących

Krajowy System e-Doręczeń (KSD) reprezentuje całość rozwiązania  informatycznego odpowiedzialnego za obsługę usługi rejestrowanego doręczenia elektronicznego (PURDE) oraz usługę hybrydową doręczenia wiadomości (PUH), w ramach projektu e-Doręczenia.  Wszystkie funkcje biznesowe (związane m.in. z przygotowywaniem, wysyłką, odbiorem, pozyskiwaniem informacji o potwierdzeniach oraz zarządzaniem ustawieniami skrzynki) realizowane są przez aplikacje klienckie eDoręczeń. 

Kluczowym komponentem w tych procesach jest wywoływanie metod zestandaryzowanego UA API (User Agent - Application Programming Interface) , implementowanego przez system dostawcy usług.  Realizacja KDS opiera się na następujących kluczowych decyzjach (zał. B specyfikacji):

• Spójność interfejsów usługi elektronicznej i hybrydowej w kwestii sposobu realizacji usług elektronicznych i usługi hybrydowej:

• Decyzja o wyborze rodzaju usługi leży po stronie użytkownika reprezentującego nadawcę wiadomości i jest wprost wyrażana w ramach przygotowania wiadomości w Aplikacji klienta.

• Przekazanie wiadomości elektronicznej i hybrydowej do wysłania pomiędzy Aplikacją klienta i Systemem Operatora będzie realizowane tą samą funkcją API.

• Procesy elektroniczny i hybrydowy rozdzielają się jak najwcześniej po stronie systemu Dostawcy usług nadawcy – identyfikowanie procesu/rodzaju wysyłki następuje na podstawie parametrów zawartych w wiadomości.

• Systemy wykorzystywane do obsługi korespondencji podłączane są bezpośrednio do UA API.

e-Doręczenia stanowią kompletny system obsługi doręczeń. Zgodnie ze specyfikacją realizacja wysyłki poprzez dowolną aplikację klienta  e-Doreczeń skutkuje tymi  takimi samymi akcjami po stronie operatora. Akcję te powodują utworzenie artefaktów w systemie operatora. W szczególności wszystkie potwierdzenie mają status dokumentów elektronicznych to znaczy są niezmienne, posiadają jednoznaczny identyfikator i  są osadzone w repozytorium dokumentów elektronicznych operatora.  Dostęp do dowolnego istotnego dokumentu elektronicznego na podstawie jego identyfikatora zapewniony jest przez UA API. Zauważmy, że właścicielem dokumentów potwierdzeń jest operator, który zapewnia ich trwałość na odpowiedni, wynikający z ustawy czas. 

Opracowano na podstawie dokumentacji e-Doręczenia – Projekt Techniczny  

Wysyłka

Z punktu widzenia nadawcy obsługa wysyłki sprowadza się do następujących czynności:

1. Przygotowanie dokumentu elektronicznego pisma.

2. Przygotowanie przesyłki elektronicznej; załączenie dokumentu, wybór sposobu dostarczenie PURDE/PUH, przygotowanie popranych danych adresowych.

3. Zlecenia akcji wysyłki przez UA API w aplikacji klienta eDoreczeń.

4. Pobranie elektronicznej  dokumentacji potwierdzeń przez UA API  w aplikacji klienta eDoreczeń.

5. Ewidencja potwierdzeń we własnych systemach

6. Sprzątanie skrzynki nadawczej przez UA API  w aplikacji klienta eDoreczeń.

Krok pierwszy i drugi  to typowe gorące procesy biurka realizowane całkowicie przez nadawce. W ich wyniku przekazujemy do eDoręczęń wszystkie wymagane artefakty wysyłki. Możemy go porównać do przygotowania emaila z załącznikiem, w formie draftu.  System eDorczenia dostarcza mechanizmy do przygotowywania takich draftów po stronie operatora ale  pozawala tez przekazać  komplet danych bez draftowania. Nadawca ma pełny wybór w sposobie przygotowania  przesyłki byle był zgodny ze specyfikacją.  Właściwa wysyłka rozpoczyna się z chwilą wysłania zlecenia (p. 3).   Po walidacji danych zlecania, operator przejmuje na czas doręczenia odpowiedzialność za przesyłkę (podobnie jak poczta przejmuje list). W trakcie realizacji dostarczania operator generuje szereg potwierdzeń (pełna lista w załączniku A specyfikacji) związanych z wybranym kanałem komunikacji. Nadawca może je pobrać (p.4) w celu zachowania kopii na własne potrzeby (p.5).  Zauważmy, że to typowe chłodne procesy szafy. W repozytorium musimy umieści odpowiednie dokumenty potwierdzeń a w szafie EZD powiązane metadane.   W ramach eDoreczeń każdemu adresowi ADE przypisana jest ograniczona przestrzeń danych, która jest wykorzystywana  przy wysyłce dokumentów, nadawca musi zadbać o zarządzanie tą przestrzenią (p.6).

Uwagi

Przedstawione w opisie wysyłki czynności skutkujące wywołaniami UA API (p.3,4,6 oraz p.2 w przypadku draftowania w systemie operatora) mogą być realizowane przez  różne aplikacje klienta eDoreczeń, co wynika bezpośrednio z roli UA API wskazanej w specyfikacji. Sytuacje można porównać korzystania do obsługi skrzynki email z różnych urządzeń; komputera, tabletu, komórki - użytkownik może pisać, wysyłać, odczytywać i usuwać male z dowolnego urządzenia, wyniki tych akcji widoczne są dla pozostałych.

W  PURDE/PUH  można przygotować wysyłkę pisma do wielu adresatów jednocześnie. Zgodnie ze specyfikacją, z tak przygotowanego draftu wiadomości system operatora przygotuje osobne przesyłki (z osobnymi identyfikatorami przesyłki) do każdego adresata i dla każdej takiej przesyłki wygeneruje osobne zestawy potwierdzeń.

Zgodnie z reguła R1 specyfikacji dla wysyłki hybrydowej jako załączniki dozwolone są tylko pliki pdf.

Rozważmy scenariusz, w którym punktem wyjścia jest poprawny dokument elektroniczny pisma tworzącego akta wychodzące w sprawie. Dokument taki posiada identyfikator. Dostarczenie realizowane jest przez eDorczecznie, które stanowi wzorcowy model dostarczania dla wiadomości elektronicznych niezależnie od kanału komunikacji PURDE/PUH.  

W przypadku dokumentów, w których adresat pisma jest jeden, mamy klarowną sytuację, do repozytorium wprowadzamy dokument, który staje się dokumentem wychodzącym w relacji 1:1, potwierdzenia prowadzone są w relacji z metadanymi pisma wychodzącego. W przypadku decyzji wydawanej zbiorczo dla grupy podmiotów, np. decyzji o wymiarze podatkowym dla nieruchomości mającej kilku współwłaścicieli odpowiadających solidarnie, trzeba ustalić na jakim poziomie utworzyć zwielokrotnienie pozwalające skutecznie skomunikować decyzje. Możliwych jest kilka scenariuszy. 

 W pierwszym zwielokrotniony samą decyzję pozostawiając jej wspólny znak, czyli tworzymy tyle dokumentów elektronicznych ile będzie wysyłek, dokumenty takie mają wspólną część merytoryczna, ale osobne wskazanie adresata, osobny podpis elektroniczny a przede wszystkim osobny identyfikator w repozytorium i osobne metadane dokumentu wychodzącego. 

 Drugi sposób polega na utworzeniu jednego elektronicznego dokumentu decyzji, dla którego  każdemu adresatowi tworzymy pismo przewodnie z informacja o wydanej decyzji z załączoną decyzją. Dla każdego pisma przewodniego z załącznikiem tworzymy metadane pisma wychodzącego. Taki konglomerat możemy umieścić w repozytorium dokumentów elektronicznych na dwa sposoby:

• Pismo przewodnie wraz załącznikiem potraktujemy jako osobna całość pod osobnym identyfikatorem, czyli w metadanych dokumentu wychodzącego wskazujemy identyfikator pisma przewodniego.

• W metadanych dokumentu wychodzącego wskazujemy identyfikator decyzji (pisma głównego). Pismo przewodnie traktujemy jako element składowy dostarczenia, tak jak zwrotkę w liście tradycyjnym ZPO, umieszczamy go składzie zgodnie z przyjęta polityka składowanie potwierdzeń. 

 Teoretycznie w przypadku wysyłki elektronicznej można zarejestrować jeden dokument wychodzący z wieloma adresatami email (traktujemy eDoreczenie jako specyficzną pocztę elektorniczna) a wszystkie dokumenty potwierdzeń do różnych adresatów połączyć pod wspólnym dokumentem. Uzyskamy wtedy efekt braku redundancji dokumentów elektronicznych za cenę niekonwencjonalnego traktowania metadanych pisma wychodzącego. Standardowy zestaw metadanych nie pozwala w wygony sposób opisać takiego scenariusza – ustawowe metadane nie przewidują odpowiednich wielokrotności. Znacznie lepszy efekt osiągniemy stosując scenariusz drugi.

@2025 ALGOR Informatyzacja Przedsiębiorstw Sp. o.o.