XML w zarządzaniu formularzami ubezpieczeniowymi ZUS Szymon Zioło Dyrektor Działu Usług empolis Polska

Czym jest KEDU – Wersja I? Kolekcja Elektronicznych Dokumentów Ubezpieczeniowych. Prosta aplikacja SGML. Modelowanie (SGML) do poziomu bloków danych. Stałopozycyjny zapis danych elementarnych – tak, jak na papierze. Głównym tematem wystąpienia jest wersja XML, ale nie mogłaby zaistnieć bez swojej poprzedniczki wykonanej zgodnie z SGML Nazwa pochodzi od Kolekcja Elektronicznych Dokumentów Ubezpieczeniowych Prosta aplikacja SGML – z całego bogactwa standardu tylko reguły zawierania się elementów Modelowanie do poziomu bloków danych – oznaczanych liczbami rzymskimi Dane elementarne zapisane w sposób stałopozycyjny – tak, jak na formularzu papierowym Polskie znaki – kod 8 bitowy w standardzie ISO 8859-2 Dedykowana aplikacja do weryfikowania formatu i dziedziny danych

Dlaczego opracowano następcę? Zmiana wymagań ZUS na informacje ubezpieczeniowe od płatników: Nowa edycja formularzy ubezpieczeniowych – tzw. seria „B”, Konieczność dostosowania systemu do obsługi nowych formularzy. Przy okazji: Usunięcie niedogodności ujawnionych podczas eksploatacji, Zmiana technologii na bardziej „przyjazną”. Po co opracowujemy następcę mając działające rozwiązanie? Zmiana wymagań ZUS w zakresie informacji ubezpieczeniowych od płatników Skutek – nowa edycja formularzy ubezpieczeniowych: seria „B” Konieczność dostosowania systemu do obsługi nowych formularzy Przy okazji Usunięcie niedogodności Zmiana technologii Rok 1998: początek prac nad wersją I – SGML: jedyny liczący się standard, drogie narzędzia, trudności z kadrą Rok 2000: rozpoczęcie prac nad wersją II – XML: dobrze „okrzepniety”, otoczony pomocniczymi specyfikacjami, łatwiejszy dostęp do kadr

Czym jest KEDU – Wersja II? Aplikacja XML wykorzystująca pulę najbardziej użytecznych właściwości standardu. Modelowanie do poziomu danych elementarnych. Wsparcie w DTD mechanizmów walidacji dziedziny i formatu danych. Mechanizmy wizualizacji wykorzystujące XSLT i przeglądarkę internetową. Zespół projektowy opracowujący opracowujący drugą wersję KEDU przyjął następujące założenia: Ma powstać aplikacja XML wykorzystująca wszystkie właściwości standardu, które zostaną uznane za użyteczne. Modelowanie danych zostanie przeprowadzone do poziomu danych elementarnych W strukturę interfejsu opisaną z użyciem DTD zostaną wbudowane mechanizmy wspierające weryfikację formatu i dziedziny danych Przewidziane jest wykonanie mechanizmu wizualizującego zawartość dokumentu typu KEDU z wykorzystaniem przeglądarki internetowej Przy opracowywaniu rozwiązania będziemy się wspierać wiedzą konsultantów z zewnętrznych firm Uprzedzając dalsze wypadki mogę stwierdzić, że rozwiązanie to zostało już wytworzone i oczekuje na wdrożenie. Sam moment wdrożenia jest zależny od decyzji ZUS o wprowadzeniu do użytku dokumentów ubezpieczeniowych serii „B”

KEDU wersja II Dane zorganizowane w sposób hierarchiczny Element nadrzędny – Kolekcja W skład kolekcji wchodzą dokumenty Dokumenty dzielą się na bloki W blokach są pola Pola albo są danymi elementarnymi, albo składają się z segmentów stanowiących dane elementarne Teraz -> Szymon Zioło

Logiczny model struktury dokumentów Semantyczny: Składniowy: DRZB DRZB dane-organizacyjne DRZB.01 termin-przys-dekl DRZB.01.01 ident-deklaracji DRZB.01.02 ... ... dane-ident-platnika DRZB.02 NIP DRZB.02.01 REGON DRZB.02.02 ... ... Model semantyczny polega na wyodrębnieniu z zestawu formularzy bloków i pól o takim samym znaczeniu i strukturze oraz zamodelowaniu ich jako pojedynczych elementów. Nazwy elementów opisują wówczas ich znaczenie, a nie pozycje w formularzach. Model składniowy polega na zdefiniowaniu osobnego elementu XML dla każdego pola i każdego bloku istniejących formularzy. Powtarzające się pola i bloki o tym samym znaczeniu są w tym modelu definiowane jako osobne elementy. Model ten pozwala na nadanie elementom nazw odpowiadających numeracji bloków, podbloków, pól i sekcji. RCB RCB dane-organizacyjne RCB.01 ... ... dane-ident-platnika RCB.02 ... ...

Logiczny model struktury dokumentów Model semantyczny: zwięzły i elegancki, pozwala na modelowanie relacji wiele-do-wielu, ale: nazwy szybko przestają być semantyczne. Model składniowy: łatwość automatyzacji przetwarzania: operowanie nazwami elementów, generowanie DTD oraz samych dokumentów, możliwość wzbogacenia o informacje semantyczne. Wybór: model składniowy. Wydaje się, że model semantyczny jest lepszy, bo oferuje się w nim elementami, których nazwy opisują znaczenie zawartości – zgodnie z ideologią XML-a. Ale w formularzach jest wiele pól o „barokowych” opisach, np. Liczba dni kalendarzowych, za które należy opłacić składki za dany miesiąc (wpisać tylko dla osób, które mają ustaloną minimalną podstawę, gdy liczba ta jest mniejsza niż liczba dni w danym miesiącu). Takie nazwy trzeba by skracać, co doprowadziłoby do bałaganu przy tworzeniu skrótów. Skróty przestały by być semantyczne i nie byłoby gwarancji, że niechcący nie skrócimy dwóch różnych nazw do tego samego skrótu. Wybraliśmy model składniowy, mimo jego rozwlekłości i brzydoty. Można go bowiem wzbogacić o informacje semantyczne np. w postaci atrybutów OPIS zawierających etykiety pól z formularzy papierowych. Po takim wyborze jedynym wyjściem było wygenerowanie DTD z bazy danych zawierającej definicje bloków, podbloków, pól i sekcji.

Modelowanie informacji dodatkowych Informacje dodatkowe –parametry elementów struktury: opisy pól, informacje o sposobie weryfikacji zawartości pól, informacje o polach wypełnianych przez ZUS. Sposób kodowania: atrybuty #FIXED: umieszczane w DTD wraz z wartościami, wartości dostępne w instancji dokumentu, nie ma możliwości zmiany wartości atrybutu w instancji dokumentu. Informacje zwrotne powinny być zakodowane w DTD w sposób umożliwiający ich wykorzystanie przez aplikacje generujące lub przetwarzające dokumenty. Takim sposobem mogą być atrybuty #FIXED, których ustalone wartości (tylko do odczytu) podaje się w DTD.

Informacje dodatkowe – przykład <!ENTITY % a.wypelnia.zus "WYPELNIA.ZUS CDATA #FIXED 'TAK'"> <!ELEMENT DRSB.01.04 (#PCDATA)> <!ATTLIST DRSB.01.04 OPIS CDATA #FIXED "Data nadania" TYP CDATA #FIXED "data" DLUGOSC CDATA #FIXED "8" %a.wypelnia.zus;> <!ELEMENT DRSB.02.04 (#PCDATA)> <!ATTLIST DRSB.02.04 OPIS CDATA #FIXED "Rodzaj dokumentu" TYP CDATA #FIXED "kod" SLOWNIK CDATA #FIXED "rodzaj.dok"> Atrybut OPIS zawiera etykietę pola taką, jak na formularzu papierowym. Informacje semantyczne są kodowane przy pomocy atrybutów TYP, DLUGOSC oraz FORMAT. TYP zawiera nazwę typu (lista typów jest ustalona). FORMAT zawiera wyrażenie regularne opisujące dopuszczalny format zawartości pola. Jeżeli wartość pola należy do ustalonego zbioru wartości (kodów), wówczas przy pomocy atrybutu SLOWNIK odwołujemy się do słownika (umieszczonego w osobnym pliku) zawierającego zbiór dopuszczalnych wartości. Informacja o tym, że pole jest wypełniane przez ZUS jest podawana przy pomocy atrybutu WYPELNIA.ZUS, którego – dla ułatwienia zarządzania – używa się przy pomocy encji parametrycznej a.wypelnia.zus.

Informacje zwrotne – implementacja Problemy: może być więcej niż jeden błąd lub korekta, dotycząca tego samego pola, zawartości mogą zawierać podelementy. Rozwiązanie: opcjonalne elementy BLAD i KOREKTA po elemencie, w którym wystąpił błąd, niemożność umieszczenia wewnątrz elementów, których dotyczą (niedozwolony model (#PCDATA, BLAD*, KOREKTA*)). Wartość pierwotna skorygowanego pola: zawartość elementu KOREKTA. Empolis Polska

Jak to wygląda w praktyce? – wypełniony formularz Widzimy fragment bloku III formularza ZUS RCB Wpisane liczby – raczej przypadkowe – chodzi wyłącznie o zasadę Większość pól to dane elementarne, pole 08 – ma segmenty

Jak to wygląda w praktyce? – reprezentacja w XML Widzimy poskracaną wersję reprezentacji elektronicznej formularza z poprzedniego slajdu Główny element – KEDU2 Element RCB – odpowiada całemu dokumentowi ZUS RCB Bloki I, II i V są „zwinięte” Blok III jest rozwinięty w całości Pole RCB.III.B.08 składa się z dwóch segmentów Do pola RCB.III.B.12 została przypięta korekta systemowa Do całego bloku RCB.III przypięto błędy

Wizualizacja formularzy Problemy: duża złożoność wizualizowanej informacji duża objętość wizualizowanych dokumentów Rozwiązanie: podział dokumentu KEDU na poszczególne formularze arkusze stylów (transformacje) XSLT generator arkuszy stylów na podstawie informacji o budowie formularza

Schemat wizualizacji Arkusz stylów Szablon Generator arkuszy stylów KEDU RCB DRSB ZEUB RSB RCB Blok powtarzalny RCB wycięcie dokumentu wycięcie instancji Szablon Generator arkuszy stylów Arkusz stylów Wizualizacja HTML

Przykład wizualizacji Empolis Polska