WYMIANA DANYCH. Wersja z dnia Numer dokumentu 2006/IT-P/003. Kategoria dokumentu. Projekt. Status dokumentu. Opracowanie wewnętrzne

Transkrypt

1 KRD.P ROTOCOLS WYMIANA DANYCH SPECYFIKACJA PROTOKOŁU NICCI Wersja z dnia Numer dokumentu Kategoria dokumentu Projekt Status dokumentu Opracowanie wewnętrzne Słowa kluczowe Biuro Informacji Gospodarczej, BIG, Rahl, Nicci, Transza, Web Service Copyright Krajowy Rejestr Długów, 2014 KRD BIG SA, ul. Armii Ludowej 21, Wrocław Tel. +48(71) , fax +48(71) ,

2 Atrybuty dokumentu Atrybut A Wartość 1 Numer 2 Projekt Rahl 3 Tytuł Wymiana danych 4 Podtytuł Specyfikacja protokołu Nicci 5 Wersja Czas wersji Kategoria Projekt 8 Plik Nicci 2.1.doc 9 Lokalizacja Informatyczny/Dokumenty/Archiwum/Projekty 10 Liczba stron Szablon Normal.dot 12 Instrukcja <BRAK> 13 Autorzy Radek Soska, Rafał Stramski 14 Nadzór Sebastian T. Tkocz 15 Dział Dział Informatyczny 16 Kontakt - rahl@krd.pl 17 Kontakt - telefon +48(71) Prawa autorskie Copyright Krajowy Rejestr Długów, Komentarz B Historia dokumentu Atrybut Wartość Data A B C 1 Wersja Autor Radosław Soska, Sebastian Tkocz 3 Sprawdził treść Mariusz Kieslich Sprawdził formę Mariusz Kieslich Zatwierdził Krzysztof Sokołowski Opis Pierwsza wersja Atrybut Wartość Data A B C 1 Wersja Autor Radosław Soska, Sebastian Tkocz 3 Sprawdził treść 4 Sprawdził formę 5 Zatwierdził Opis Aktualizacja schematu pliku importowego: - dodawanie i zatrzymywanie monitorów, 6 - zmiana właściciela informacji i sprawy, - zmiana wymagalności w typie addresstype Atrybut Wartość Data A B C 1 Wersja Autor Przemysław Grondys 3 Sprawdził treść Radosław Soska Sprawdził formę 5 Zatwierdził 6 Opis Aktualizacja wersji do 1.2; dodanie przykładów Zmiana numeru dokumentu Opracowanie wewnętrzne Strona 2 z 91 Copyright Krajowy Rejestr Długów, 2014

3 Atrybut Wartość Data A B C 1 Wersja Autor Radosław Soska 3 Sprawdził treść 4 Sprawdził formę 5 Zatwierdził 6 Opis Korekta dokumentu, aktualizacja przykładów Atrybut Wartość Data A B C 1 Wersja Autor Radosław Soska 3 Sprawdził treść 4 Sprawdził formę 5 Zatwierdził Opis Aktualizacja dokumentacji do wersji 2.0 protokołu Nicci: - rozszerzenie sekcji opisującej zlecenia, które można przekazać przy pomocy Nicci 6 - dodanie nowych elementów (np. ujawnianie informacji gospodarczych, rozszerzenie funkcjonalności monitorów, pobieranie list spraw i informacji) - nowy podział logiczny dokumentu - zmiana numeru dokumentu Atrybut Wartość Data A B C 1 Wersja Autor Rafał Stramski 3 Sprawdził treść Radosław Soska Sprawdził formę 5 Zatwierdził Sebastian T. Tkocz Opis Aktualizacja dokumentacji dla wersji 2.0 protokołu Nicci: - uzupełnienie dokumentu o nowe typy i grupy dla wersji protokołu Nicci - aktualizacja elementów Input i Output - aktualizacja przykładów Atrybut Wartość Data A B C 1 Wersja Autor Radosław Soska 3 Sprawdził treść Sebastian T. Tkocz 4 Sprawdził formę 5 Zatwierdził Opis Aktualizacja dokumentacji dla wersji 2.0 protokołu Nicci: 6 - dodanie w grupie notifydebtorgroup elementu AddressRegistered - dodanie do typu monitoreventtype elementu Date Atrybut Wartość Data A B C 1 Wersja Autor Radosław Soska 3 Sprawdził treść Sebastian Tkocz Sprawdził formę 5 Zatwierdził Opis Aktualizacja dokumentacji dla wersji 2.1 protokołu Nicci: 6 - dodanie nowego ManagementService w postaci ProcessSnapshot oraz odpowiadającemu mu ManagementResponse Opracowanie wewnętrzne Strona 3 z 91 Copyright Krajowy Rejestr Długów, 2014

4 Atrybut Wartość Data A B C 1 Wersja Autor Stramski Adam 3 Sprawdził treść Radosław Soska Sprawdził formę Radosław Soska Zatwierdził 6 Opis Aktualizacja dokumentacji dla wersji 2.1 protokołu Nicci: - pobieranie weryfikacji przy operacjach CRU Case Atrybut Wartość Data A B C 1 Wersja Autor Stramski Rafał 3 Sprawdził treść Mariusz Purwin Sprawdził formę Michał Orlik Zatwierdził 6 Opis Aktualizacja dokumentacji dla zmian po wejściu nowej ustawy Opracowanie wewnętrzne Strona 4 z 91 Copyright Krajowy Rejestr Długów, 2014

5 Spis treści SPIS TREŚCI. 5 SPIS TABEL 6 SPIS PRZYKŁADÓW.. 7 WSTĘP DANE PRZEKAZYWANE DO BIURA SPRAWY Dane dłużnika Dane zobowiązań INFORMACJE O SPŁACONYCH ZOBOWIĄZANIACH ORAZ INFORMACJE O POSŁUŻENIU SIĘ FALSZYWYM DOKUMENTEM ZLECENIA ZLECENIA DOTYCZĄCE INFORMACJI GOSPODARCZYCH ZLECENIA DOTYCZĄCE SPRAW ZLECENIA DOTYCZĄCE UJAWNIANIA INFORMACJI GOSPODARCZYCH ZLECENIA DOTYCZĄCE MONITOROWANIA ZLECENIE NIE WSPIERANE PRZEZ WERSJĘ OPIS SCHEMATU XML PLIK NICCICOMMON.XSD Typy proste Typy złożone Grupy elementów PLIK NICCIINPUT.XSD Definicje typów Element główny Input..77 PLIK NICCIOUTPUT.XSD Definicje grup Definicje typów Element główny Output 90 Opracowanie wewnętrzne Strona 5 z 91 Copyright Krajowy Rejestr Długów, 2014

6 Spis tabel Tabela 1 : Sformalizowana reprezentacja adresu 11 Tabela 2 : Dane przedsiębiorstwa 12 Tabela 3 : Dane osoby fizycznej..12 Tabela 4 : Dane zobowiązania..14 Tabela 5 : Dane zobowiązania stwierdzonego tytułem wykonawczym..14 Tabela 6 : Dane zobowiązania alimentacjnego.15 Tabela 7 : Dane zobowiązania z tytułu pieczy zastępczej.15 Opracowanie wewnętrzne Strona 6 z 91 Copyright Krajowy Rejestr Długów, 2014

7 Spis przykładów Przykład 3-1 Typ headertype 24 Przykład 3-2 Elementy Debt typu moneytype.25 Przykład 3-3 Typ addresstype format rozszerzony.26 Przykład 3-4 Typ addresstype format prosty 26 Przykład 3-5 Typ personstype..27 Przykład 3-6 Typ stakeholderstype.28 Przykład 3-7 Typ consumertype..29 Przykład 3-8 Typ legalpersontype..30 Przykład 3-9 Typ paidobligationlegalpersontype Błąd! Nie zdefiniowano zakładki. Przykład 3-10 Typ paidobligationconsumertype. Błąd! Nie zdefiniowano zakładki. Przykład 3-11 Typ paidobligationenterpreneurtype.. Błąd! Nie zdefiniowano zakładki. Przykład 3-12 Typ debtortype..31 Przykład 3-13 Typ providertype..32 Przykład 3-14 Typ paidobligationdebtortype.. Błąd! Nie zdefiniowano zakładki. Przykład 3-15 Typ caseobligationstypecaseobligation.33 Przykład 3-16 Typ documentinformationtype. Błąd! Nie zdefiniowano zakładki. Przykład 3-18 Typ obligationinformationtype..34 Przykład 3-19 Typ caseintype..34 Przykład 3-20 Typ caseouttype..36 Przykład 3-21 Typ monitoreventtype.37 Przykład 3-22 Typ requestertype 38 Przykład 3-23 Typ searchcriteriontype..38 Przykład 3-24 Typ obligationinformationdrtype.39 Przykład 3-25 Typ paidobligationinformationdrtype 40 Przykład 3-26 Typ disclosurereporttype41 Przykład 3-27 Typ disclosurereportstype.42 Przykład 3-28 Typ casestype 43 Przykład 3-29 Typ snapshottype.43 Przykład 3-31 Typ monitorconditionstype 44 Przykład 3-34 Typ casefiltertype 45 Przykład 3-35 Typ informationfiltertype 48 Przykład 3-36 Grupa identifiergroup w elemencie Debtor 49 Przykład 3-37 Grupa registrationgroup.49 Przykład 3-38 Grupa identitycardgroup 50 Przykład 3-39 Grupa propertygroup 50 Przykład 3-40 Grupa legalpersondatagroup.51 Przykład 3-41 Grupa consumerdatagroup 52 Przykład 3-42 Grupa streetgroup z prefiksem.53 Przykład 3-43 Grupa streetgroup z postfiksem 53 Przykład 3-44 Grupa notifydebtorgroup 54 Przykład 3-45 Grupa obligationdatagroup w elemencie CaseObligation..55 Przykład 3-46 Grupa documentseriesnumbergroup..56 Przykład 3-47 Grupa documentinformationgroup..57 Przykład 3-48 Grupa paidobligationinformationgroup..57 Przykład 3-49 Grupa obligationinformationgroup..58 Przykład 3-50 Grupa monitorconditiongroup..59 Przykład 3-51 Grupa personnamegroup 59 Przykład 3-52 Grupa peselgroup.59 Przykład 3-53 Typ orderbasetype 60 Przykład 3-54 Typ serviceorderbasetype.61 Przykład 3-55 Typ addcasetype..61 Przykład 3-56 Typ updatecasetype 62 Przykład 3-57 Typ removecasetype..62 Opracowanie wewnętrzne Strona 7 z 91 Copyright Krajowy Rejestr Długów, 2014

8 Przykład 3-58 Typ suspendtype..63 Przykład 3-59 Typ unsuspendtype..64 Przykład 3-60 Typ suspendcaseobligationtype..64 Przykład 3-61 Typ unsuspendcaseobligationtype..65 Przykład 3-67 Typ addmonitorconditiontype 65 Przykład 3-68 Typ updatemonitorconditiontype.66 Przykład 3-69 Typ stopmonitorconditiontype..66 Przykład 3-70 Typ removemonitorconditiontype 67 Przykład 3-71 Typ changeownertype.67 Przykład 3-72 Typ changeinformationownertype..68 Przykład 3-73 Typ searchleagalpersontype.69 Przykład 3-74 Typ searchconsumertype..69 Przykład 3-75 Typ searchdocumenttype..70 Przykład 3-76 Typ searchmetype.70 Przykład 3-77 Typ searchregistrytype..70 Przykład 3-78 Typ getdisclosurereporttype.71 Przykład 3-79 Typ getdisclosurereportstype..71 Przykład 3-80 Typ getcasestype.72 Przykład 3-82 Typ processsnapshottype..72 Przykład 3-83 Typ serviceordertype..74 Przykład 3-84 Typ serviceorderstype.74 Przykład 3-85 Typ managementordertype..75 Przykład 3-86 Typ managementorderstype.76 Przykład 3-87 Typ searchordertype 76 Przykład 3-88 Typ searchorderstype.77 Przykład 3-89 Element Input.77 Przykład 3-90 Grupa responsegroup..78 Przykład 3-91 Typ successtype 79 Przykład 3-92 Typ failtype.79 Przykład 3-93 Typ simpleresponsetype 80 Przykład 3-94 Typ monitorresponsetype..80 Przykład 3-95 Typ responsetype.81 Przykład 3-96 Typ disclosurereportresponsetype.81 Przykład 3-97 Typ disclosurereportsresponsetype 82 Przykład 3-98 Typ searchregistryresponsetype.83 Przykład 3-99 Typ casesresponsetype..83 Przykład Typ monitorconditionsresponsetype 84 Przykład Typ monitoreventsresponsetype..85 Przykład Typ snapshotaddcasetype..85 Przykład Typ snapshotupdatecasetype.86 Przykład Typ snapshotremovecasetype..86 Przykład Typ snapshotserviceorderstype.87 Przykład Typ processsnapshotresponsetype..87 Przykład Typ serviceresponsetype.88 Przykład Typ managementresponsetype.89 Przykład Typ searchresponsetype.90 Przykład Element Output 91 Opracowanie wewnętrzne Strona 8 z 91 Copyright Krajowy Rejestr Długów, 2014

9 Wstęp Protokół NICCI jest schematem opisującym strukturę danych złużącą do wymiany informacji pomiędzy systemami KRD, a systemami zewnętrznymi. Wersja 2.1 protokołu NICCI przygotowana została jeszcze w czasie obowiązywania starej ustawy o BIG, z 2003 roku, dlatego użyte w tej wersji protokołu pojęcia odpowiadają jej definicjom. Po wejściu w życie nowej ustawy (dnia 9 kwietnia 2010 roku) system KRD przeszedł gruntowne zmiany. Oczywiście schemat transzy, ze względu na używanie go przez wielu klientów nie mógł zostać zmieniony. Umożliwiono jednak przekazywanie transz NICCI 2.1 także tym klientom, których dane pozostają w zgodności z nową ustawą, ale musiało się to odbyć kosztem pewnych kompromisów. Dla przykładu, wg nowej ustawy informacja gospodarcza o dłużniku będącym konsumentem może zawierać od jednego do trzech adresów konsumenta (zamieszkania, zameldowania, korespondencyjny). Wg starej ustawy można było podać tylko adres zameldowania. Jeżeli zatem klient wprowadzi do systemu KRD informacje wykraczające poza zakres starej ustawy (np. poprzez stronę WWW), to protokół NICCI 2.1 nie będzie mógł posłużyć do pobrania takiej informacji. Dokument ten opisuje strukturę danych przekazywanych do biura oraz strukturę raportu biura z wykonania zleconych usług. Opisany zostanie także schemat plików XML (transz) zawierających te dane. Tam gdzie uwidaczniać się będą różnice między definicją protokołu NICCI a aktualnym stanie systemu pojawiać się będzie stosowna informacja. Nie wspierane już zlecenia zebrane są w punkcie 2.6, a ich opisy i przykłady zostały z dokumentacji usunięte. Opracowanie wewnętrzne Strona 9 z 91 Copyright Krajowy Rejestr Długów, 2014

10 1. Dane przekazywane do biura Dane, które można przekazać do biura infomacji gospodarczej reguluje ustawa. Określa ona minimalny i maksymalny zakres danych, a także dodatkowe warunki jakie muszą zostać spełnione, by biuro miało prawo te dane przyjąć. Biuro może przyjąć trzy rodzaje informacji gospodarczej. Pierwszym typem informacji są informacje o niespełnionych zobowiązaniach, zarówno podmiotów gospodarczych jak i osób fizycznych. Grupowane są one dla jednego dłuznika w pojęcie sprawy. Sprawa zawiera informacje o dłuzniku, o wierzycielu (może on zastrzec sobie ujawnianie swoich danych) oraz o niespełnionych zobowiązaniach dłużnika wobec wierzyciela. Pojęcie sprawy widoczne jest jedynie dla klienta wprowadzającego tę sprawę. Dla osób trzecich, którym zostaną ujawnione informacje gospodarcze dotyczące dłużnika, zobowiązania jednej sprawy widoczne będą jako nie powiązane ze sobą (poza danymi wierzyciela, jeśli nie zastrzegł on sobie ich ujawniania) informacje gospodarcze dotyczące niespełnionych zobowiązań. Drugim typem informacji gospodarczej jest informacja o spełnionych zobowiązaniach. Klient na żądanie swego kontrahenta przekazuje do biura informację o łącznej kwocie i walucie zobowiązań spełnionych przez jego kontrahenta w ciągu ostatnich 5 lat, z wyszczególnieniem kwoty tych zobowiązań, które zostały spełnione z opóźnieniem nie dłuższym niż 14 dni. Trzecim typem informacji gospodarczej jest informacja o posłużeniu się wobec klienta biura podrobionym lub cudzym dokumentem. Ze względu na znaczące zmiany wprowadzone w Ustawie z dnia 14 czerwca 2010, a dotyczące informacji o spłaconych zobowiązaniach oraz posłużeniu się podrobionym lub fałszywym dokumentem, transze w wersji 2.1 i niższych nie obsługują już tego typu danych Sprawy Sprawa to grupa informacji gospodarczych dotyczących zobowiązań jednego dłuznika wobec klienta zgłaszającego te informację. Sprawę zgłasza się do biura w całości tzn. podając wszystkie zobowiązania. Po dodaniu sprawy do biura można sprawę usunąć, bądź zmodyfikować. Modyfikacja sprawy polega na modyfikacji danych dłużnika albo na usunięciu bądź modyfikacji jednego z zobowiązań tej sprawy. Sprawa składa się z identyfikatora, nadawanego przez wierzyciela numeru sprawy, danych dłużnika, danych zobowiązań (co najmniej jednego) oraz dodatkowych właściwości określanych przez wierzyciela. Identyfikatorem może być guid ( globally unique identifier ) lub zdefiniowany przez klienta, niepusty ciąg znaków. W każdym przypadku klient jest odpowiedzialny za unikalność podawanego identyfikatora Dane dłużnika Dłużnikiem klienta może być osoba fizyczna, osoba prawna lub jednoosobowa działalność gospodarcza. Opracowanie wewnętrzne Strona 10 z 91 Copyright Krajowy Rejestr Długów, 2014

11 Podmiot gospodarczy Wymagane dane przedsiębiorstwa ( podmiotu będącego osobą prawną lub jednostką organizacyjną nieposiadającą osobowości prawnej ) to oznaczenie, siedziba i adres oraz numer identyfikacji podatkowej. Opcjonalnie można podać numer REGON, numer pod którym podmiot wpisany jest do właściwego rejestru (wraz z oznaczeniem sądu rejestrowego) oraz główny przedmiot działalności gospodarczej. Numer identifikacji podatkowej może być podany jako ciąg 10 cyfr bez kresek, bądź jako oddzielone kreskami: 3, 3, 2 i 2 cyfry (np ) lub 3, 2, 2 i 3 cyfry (np ). Numer REGON to 9 cyfr. Możliwe jest podanie tylko identyfikatora NIP podmiotów zarejestrowanych w Polsce. Adres może być opisany na dwa sposoby: w pełni sformalizowany (jak na przykład w formularzach PIT), w którym podajemy jawnie co jest numerem mieszkania, a co nazwą ulicy (patrz przykład 3-4) lub jako ciąg 2 do 4 linii, w których powinny się znaleźć wszystkie dane potrzebne do dostarczenia przesyłki, czyli conajmniej kod pocztowy i nazwa miejscowości, oraz wskazanie posesji (np. ulica i numer domu). Pokazuje to przykład 3-5. Sposób formalnego przedstawienia adresu pokazany jest w tabeli 1. Tabela 1 : Sformalizowana reprezentacja adresu Dana Opis Uwagi Krotność A B C D 1 STREETPREFIX Przedrostek ulicy Np. ul., plac STREET Nazwa ulicy Jeśli nie podano, to trzeba podać 1 miejscowość (6) 3 STREETPOSTFIX Przyrostek ulicy (występuje za granicą) Np. Avenue BUILDING Numer budynku Np. 15A, FLAT Numer mieszkania Np. 10, 2a CITY Nazwa miejscowości, jeśli inna niż poczty ZIPCODE Kod pocztowy Np POST Nazwa miejscowości, w której jest poczta 1 9 COUNTRY Nazwa kraju (zakładamy Polskę, jeśli brak) 0..1 POSTSCRIPT Dopisek adresu. Nie wchodzi w skład 10 informacji gospodarczej w rozumieniu ustawy. Może zostać użyty przy wysyłaniu listu do dłużnika Np. księgowość DESCRIPTION Opis adresu. Nie wchodzi w skład informacji gospodarczej w rozumieniu ustawy. Widoczny tylko dla wprowadzającego dane Np. Adres domowy Zarówno opis (DESCRIPTION) jak i dopisek (POSTCRIPT) nie są informacją gospodarczą w rozumieniu ustawy, więc nie zostaną ujawnione osobom trzecim. Dopisek, jeśli zostanie podany, znajdzie się na adrasie ewentualnych powiadomień wysyłanych przez biuro do dłużnika. Jeśli dłużnikiem jest przedsiębiorstwo jednosobowe, można podać dane osoby fizycznej, która jest tym przedsiębiorstwem. Dane te nie muszą spełniać ustawowych wymogów dotyczących zakresu wymaganych danych osoby fizycznej Opracowanie wewnętrzne Strona 11 z 91 Copyright Krajowy Rejestr Długów, 2014

12 Dodatkowo można podać imiona i nazwiska osób wchodzących w skład organów zarządzających, prokurentów lub pełnomocników tego podmiotu. W tym zakresie danych nowa ustawa zezwala na przyjmowanie jedynie imiona i nazwiska pełnomocników co powinno być oznaczone w polu Role słowem pełnomocnik. W przypadku podania innej roli system nie przetworzy zlecenia. Wprowadzając informację gospodarczą o zobowiązaniach przedsiębiorcy (sprawę) można także podać dane: Wspólników dłużnika będącego spółką z ograniczoną odpowiedzialnością, posiadającego co najmniej 100% kapitału zakładowego tej spółki Akcjonariusza dłużnika będącego jednoosobową spółką akcyjną Tabela 2 : Dane przedsiębiorstwa Dana Opis Uwagi Krotność A B C D 1 NAME Nazwa (oznaczenie) przedsiębiorstwa Niepusty tekst 1 2 NIP Numer identyfikacji podatkowej 1 3 REGON Numer regon przedsiębiorstwa REGISTRATIONNUMBER Numer w rejestrze Muszą wystąpić 5 REGISTRYNAME Nazwa rejestru, w którym jest w/w numer razem 1 6 SEATADDRESS Siedziba i adres Patrz Tab EKD Numer EKD (Europejska Klasyfikacja Działalności) PERSONS Lista osób powiązanych z firmą 0..1 Dane te, oprócz tych opisujących przedsiębiorstwa (tabela 1-2), mogą też zawierać dane osób fizycznych, które są przedsiębiorcami i wspólnikami bądź akcjonariuszami (jednoosobowymi) dłużnika (tabela 1-3). Date te nie są jednak wymagane, więc nie podlegają rygorom wymagalności określanym dla dłużnika. Można więc podac np. tylko numery NIP wspólników. Obecnie system KRD nie wspiera tych danych. Zlecenie zawierające dane wspólników nie zostanie przetworzone. Ustawa z 2003 roku pozwalała na podanie wielu udziałowców dłużnika, ale wg nowej ustawy można podać tylko jednego udziałowca takiego który posiada 100% udziałów w spółce kapitałowej (100% akcji spółki akcyjnej lub 100% udziału w kapitale spółki z o.o.) Osoba fizyczna Wymagane dane osoby fizycznej to imię i nazwisko, oraz numer PESEL (dla obywateli polskich). Pozostałe, opcjonalne dane to obywatelstwo, typ, seria i numer dokumentu tożsamości oraz adres zameldowania (na pobyt stały lub czasowy). Jeśli dłużnikiem jest osoba fizyczna prowadząca działalność gospodarczą, można podać dane jego przedsiębiorstwa, dane te nie podlegają jednak wtedy ustawowym wymogom wymagalności danych osób prawnych. Tabela 3 : Dane osoby fizycznej Dana Opis Uwagi Krotność A B C D 1 FIRSTNAME Imię 1 2 SECONDNAME Drugie imię SURNAME Nazwisko 1 4 CITIZENSHIP Obywatelstwo 1 Opracowanie wewnętrzne Strona 12 z 91 Copyright Krajowy Rejestr Długów, 2014

13 5 PESEL Numer PESEL (wymagany dla obywateli polskich) 6 IDENTITYCARD Opis dokumentu potwierdzającego tożsamość Seria i numer ADDRESS Adres zameldowania (pobyt stały lub czasowy) Patrz Tab BIRTHDAY Data urodzin Jednoosobowa działalność gospodarcza. Ten rodzaj dzłożnika został doprecyzowany przez ustawę z 14 czerwca 2010 roku. Podstawowymi danymi wymaganymi do przekazania dłużnika będącego jednoosobową działalnością gospodarczą jest oznaczenie dłużnika, numer identyfikacji podatkowej (NIP lub inny w przypadku podmiotów zagranicznych) oraz adres pod którym wykonywana jest działalność. Nowa ustawa jako oznaczenie przedsiębiorcy prowadzącego jednoosobową działalność gospodarczą wymaga oprócz nazwy, podania imienia i nazwiska właściciela np. P.H.U. Handlex Jan Kowalski. Zatem minimalny zestaw danych dla tego typu dłużnika składa się z oznaczenia (z imieniem i nazwiskiem) w polu Name, numeru NIP oraz pól FirstName i Surname. Aby przekazać informacje tego rodzaju dłużnika poprzez protokół NICCI zaleca się użycie elementu LegalPerson uzupełniony o co najmniej imię i nazwisko osoby fizycznej Dane zobowiązań Zobowiązanie opisane jest co najmniej trzema elementami: tytułem prawnym zobowiązania, kwotą i walutą zaległości oraz datą powstania zaległości. Tytuł prawny składa się z dwóch pól: Title oraz Type przy czym należy podać co najmniej jeden z nich. Jeżeli w polu Title wpiszemy pełny tytuł prawny np. Faktura VAT 123/A/2010, a pole Type pozostawimy puste, to system będzie próbował dopasować z istniejącego słownika typ zobowiązania. Jeżeli początek ciągu znaków w polu Title będzie zawierał pasujący element słownika, to zostanie on przeniesiony do pola Type. Dodatkowo podać można kwotę i walutę zobowiązania (kwoty te będą różne np. wtedy, kiedy zobowiązanie zostało częściowo spłacone). Do danych wierzytelności można także dodać opis stanu postępowań dotyczących zobowiązania (np. o toczących się postępowaniach sądowych lub egzekucyjnych) oraz informację o kwestionowaniu przez dłużnika całości bądź części zobowiązania. Opisy te mają formę luźnego tekstu o maksymalnej długości 1024 znaków. Pominięcie pola o kwestionowaniu przez dłużnika całości lub części zobowiązania zostanie oznaczone w systemie jako dłużnik nie zgłasza zarzutów. Do systemu KRD możliwe jest przekazywanie czterech rodzajów zobowiązań: zwykłe, alimentacyjne, stwierdzone tytułem wykonawczym oraz z tytułu pieczy zastępczej. Trasza NICCI pozwala na przekazanie w jednej sprawie (patrz punkt 2.2) tylko jednego rodzaju zobowiązania. Przekazując do biura dane o zobowiązaniu zwykłym lub stwierdzonym tytułem wykonawczym klient musi podać datę wysłania do dłużnika wezwania do zapłaty tego zobawiązania. To wezwanie do zapłaty musi zawierać ostrzeżenie o zamiarze przekazania danych do biura informacji gospodarczej, z podaniem nazwy i adresu siedziby tego biura. Opracowanie wewnętrzne Strona 13 z 91 Copyright Krajowy Rejestr Długów, 2014

14 Zobowiązanie zwykłe Aby informacja o tego typu zobowiązaniu mogła zostać przyjęta przez biuro, przekazane dane muszą spełniać trzy warunki (poza dostarczeniem minimalnych danych): Zobowiązanie jest wymagalne od co najmniej 60 dni (czyli od daty PaymentDate minęło 60 dni) Upłynął co najmniej miesiąc od wysłania wezwania do zapłaty (czyli od daty CallSent ) Łączna kwota zobowiązań dłużnika wobec klienta przekroczyła 200zł jeśli dłużnikiem jest konsument, oraz 500zł jeśli dłużnikiem jest podmiot gospodarczy. Naturalnie spełnione muszą być też wszystkie pozostałe, określone przez ustawe wymogi, które nie są wyspecyfikowane w danych. Dane zobowiązania przekazywane do biura zebrane są w tabeli 1-2. Tabela 4 : Dane zobowiązania Pole Opis Uwagi Krotność A B C D 1 TITLE Tytuł prawny zobowiązania, np. Faktura 145/A/02 Element niepusty 1 2 TYPE Rodzaj zobowiązania, np. faktura, odsetki. Patrz tekst DEBT Kwota i waluta zobowiązania Patrz moneytype ARREARS Kwota i waluta zaległości Patrz moneytype 1 5 PAYMENTDATE Data powstania zaległości 1 6 PROCEEDINGS Opis stanu postępowań dotyczących tego zobowiązania OBJECTIONS Informacja o kwestionowaniu przez dłużnika całości lub części zobowiązania. Może być pusty CALLSENT Data wysłania do dłużnika wezwania do zapłaty Patrz tekst Zobowiązanie stwierdzone tytułem wykonawczym Ten szczególny rodzaj zobowiązania skierowany jest do wierzycieli, którzy posiadają do niego tytuł wykonawczy np. wyrok sądu. Jako tytuł prawny zobowiązania należy podać rodzaj tytułu wykonaczego, datę wystawienia, nazwę organu, który go wystawił oraz sygnaturę. Należy również wskazać datę powstania zaległości, oraz datę wysłania powiadomienia o zamiarze dopisania zobowiązania do KRD. Od daty wysłania powiadomienia musi upłynąć conakmniej 14 dni. Dla tego typu zobowiązań nie ma określonej minimalnej kwoty. Musi ona być jedynie większa od zera. Tabela 5 : Dane zobowiązania stwierdzonego tytułem wykonawczym Pole Opis Uwagi Krotność A B C D 1 EXECUTIVETYPE Tytuł wykonawczy, np. Wyrok Sądu Element niepusty 1 2 EXECUTIVEOBLI Data wydania tytułu wykonawczego GATIONDATE 1 3 SIGNATURE Sygnatura tytułu wykonawczego 1 4 DECIDINGAUTH Dane organu orzekającego ORITY 1 5 PAYMENTDATE Data powstania zaległości 1 6 PROCEEDINGS Opis stanu postępowań dotyczących tego zobowiązania OBJECTIONS Informacja o kwestionowaniu przez dłużnika całości lub części zobowiązania. Może być pusty CALLSENT Data wysłania do dłużnika wezwania do zapłaty Patrz tekst 1 9 DEBT Kwota i waluta zobowiązania Patrz moneytype ARREARS Kwota i waluta zaległości Patrz moneytype 1 Opracowanie wewnętrzne Strona 14 z 91 Copyright Krajowy Rejestr Długów, 2014

15 Zobowiązanie alimentacyjne Zobowiązania alimentacyjne mogą być łączone jedynie z dłużnikiem będącym konsumentem (Consumer). Przy tego typu zobowiązaniach wysłanie powiadomienia o zamiarze dopisania do KRD nie jest wymagane, zatem pole CallSent może zostać pominięte. W polu Title należy podać informację na jaki dzień zostało wyliczone zadłużenie. Tabela 6 : Dane zobowiązania alimentacjnego Pole Opis Uwagi Krotność A B C D 1 TITLE Data aktualna wyliczenia kwoty zadłużenia Element niepusty 1 2 DEBT Kwota i waluta zobowiązania Patrz moneytype ARREARS Kwota i waluta zaległości Patrz moneytype 1 4 PAYMENTDATE Data powstania zaległości 1 5 PROCEEDINGS Opis stanu postępowań dotyczących tego zobowiązania OBJECTIONS Informacja o kwestionowaniu przez dłużnika całości lub części zobowiązania. Może być pusty CALLSENT Data wysłania do dłużnika wezwania do zapłaty Patrz tekst Zobowiązanie z tytułu pieczy zastępczej Tabela 7 : Dane zobowiązania z tytułu pieczy zastępczej Pole Opis Uwagi Krotność A B C D 1 ASFOR Data aktualna wyliczenia kwoty zadłużenia Element niepusty 1 2 DEBT Kwota i waluta zobowiązania Patrz moneytype ARREARS Kwota i waluta zaległości Patrz moneytype 1 4 PAYMENTDATE Data powstania zaległości 1 5 PROCEEDINGS Opis stanu postępowań dotyczących tego zobowiązania OBJECTIONS Informacja o kwestionowaniu przez dłużnika całości lub części zobowiązania. Może być pusty Informacje o spłaconych zobowiązaniach oraz informacje o posłużeniu się falszywym dokumentem Protokoły NICCI w wersji 2.1 i niższej nie wspierają już tego typu informacji ze względu na znaczne zmiany zakresu danych w nowej ustawie. Opracowanie wewnętrzne Strona 15 z 91 Copyright Krajowy Rejestr Długów, 2014

16 2. Zlecenia 2.1. Zlecenia dotyczące informacji gospodarczych Do biura informacji gospodarczych można przekazywać zlecenia wykonania usług. Te usługi dotyczą zarządzania informacjami gospodarczymi (tylko zobowiązania): dodawania, modyfikacji, usuwania, zawieszania i odwieszania publikacji informacji gospodarczych. Dodanie bądź modyfikacja informacji gospodarczej, polega na przekazaniu danych tej informacji (nowych bądź zmodyfikowanych) w ramach elementu AddCaseObligation lub UpdateCaseObligation. Usunięcie, zawieszenie bądź odwieszenie informacji gospodarczej polega na przekazaniu ustalonego (w czasie dostarczania tej informacji) identyfikatora informacji w ramach odpowiednich elementów identyfikujących zlecenia. Są to odpowiednio elementy: RemoveCaseObligation, SuspendCaseObligation oraz UnsuspendCaseObligation. Dodatkowo, zawieszając publikację informacji gospodarczej należy podac datę, do której publikacja tej informacji ma być wsztrzymana. Podanie daty jest obowiązkowe, nic jednak nie stoi na przeszkodzie by podac datę bardzo odległą, np Zlecenia dotyczące spraw Pewną specyficzną grupą informacji gospodarczych są sprawy. Sprawy można dodawać i usuwać, jak i zawieszać. Zawieszanie polega na przkazaniu zlecenia SuspendCase zawierającego dwie daty: daty od kiedy sprawa ma zostać zawieszona (datefrom można ten element pominąć i przyjęta zostanie data bieżąca) oraz daty zakończenia zawieszenia sprawy (dateto element obowiązkowy). Odwieszenia dokonujemy poprzez zlecenie UnsuspendCase. Modyfikować można tylko konkretne zobowiązanie, a modyfikacja sprawy może polegac albo na modyfikacji danych dłużnika (co oznacza de facto modyfikację tych danych w każdym zobowiązaniu tej sprawy) albo na dodaniu bądź usunięciu zobowiązań. Dodanie bądź modyfikacja sprawy to przekazanie całych (nowych bądź zmodyfikowanych) danych sprawy (czyli danych dłużnika i zobowiązań) w ramach odpowiedniego elementu: AddCase bądź UpdateCase. Usunięcie sprawy polega na przekazaniu identyfikatora sprawy w kontekscie elementu RemoveCase. Możliwe są też operacje bezpośrednio na samych zobowiązaniach. Dodanie bądź modyfikacja polega na przekazaniu danych (nowych bądź zmodyfikowanych) w ramach elementu AddCaseObligation lub UpdateCaseObligation. Podczas dodawania pojedynczego zobowiązania należy dodatkowo wskazać identyfikator sprawy, do której zostanie ono dołączone. Usunięcie zobowiązania realizuje zlecenie RemoveCaseObligation przyjmujące identyfikator informacji. By zawiesić, bądź odwołać zawieszenie publikacji zobowiązania sprawy należy identyfikator tej wierzytelności przekazać w ramach odpowiedniego elmentu, czyli SuspendCaseObligation bądź UnsuspendCaseObligation. Podobnie jak w wypadku zawieszania innych informacji gospodarczych, obowiązkowe jest podanie dnia, do którego wstrzymujemy publikację tej informacji. Czyli informacja będzie ponownie publikowana dnia następnego po podanej dacie. Istnieje też możliwość wstrzymywania publikacji całych spraw. Datami w jakich wstrzymana jest publikacja sprawy jako całości manipulują zlecenia Opracowanie wewnętrzne Strona 16 z 91 Copyright Krajowy Rejestr Długów, 2014

17 typu SuspendCase i UnsuspendCase. Należy tu nadmienić, że stany wstrzymania publikacji sprawy i zobowiązań danej sprawy nie są od siebie zależne. Czyli jeżeli zawesimy publikację jednego zobowiązania, potem zawiesimy publikację całej sprawy a jeszcze później odwołamy wstrzymanie publikacji sprawy, zobowiązanie wcześniej osbono zawieszone, dalej takim pozostaje. Usunięcie wierzytelności realizujemy jako uaktualnienie danych sprawy czyli w ramach elementu UpdateCase podajemy dane sprawy pomijając wierzytelności, które chcemy usunąć. Podobnie zresztą modyfikujemy dane dłużnika jeśli chemy usunąć podanego wcześniej wspólnika, podajemy jako zaktualizowane dane tego dłużnika bez danych wspólnika. Klient ma możliwość uzyskania listy swoich spraw za pomocą zlecenia GetCases. Można także zmieniać właściela sprawy zleceniem ChangeCaseOwner. Poczynając od wersji 2.1 protokół umożliwia synchronizację listy spraw, które są w bazie KRD z listą spraw, które klient posiada w swoim systemie. Operacja ta polega na tym, że klient wysyła do KRD aktualne dane wszystkich swoich spraw (w postaci zlecenia ProcessSnapshot ) i w odpowiedzi dostaje listę zleceń, które musi przesłać do systemu KRD, aby stan bazy KRD zrównał się ze stanem bazy klienta. Lista zleceń w odpowiedzi jest fragmentem transzy XML zgodnej ze schematem protokołu Nicci. Ten fragment klient może przesłać w kolejnej transzy jako zlecenia do bazy KRD. W odpowiedzi przesyłanej do klienta znajdują się: zlecenia dodania spraw, które są w bazie klienta a nie zostały znalezione w bazie KRD, zlecenia aktualizacji dla spraw, które już zostały przez klienta przekazane do KRD, ale ich dane zostały zmienione zlecenia usunięcia tych spraw z bazy KRD, które nie znalazły się na aktualnej liście spraw uzyskanej od klienta, a były wcześniej przekazane do KRD 2.3. Zlecenia dotyczące ujawniania informacji gospodarczych Przy pomocy protokołu Nicci, począwszy od wersji 2.0, klienci mają także możliwość pozyskiwania informacji gospodarczych o innych podmiotach. W tym celu w pierwszej kolejności należy wysłać prośbę o ujawnienie informacji gospodarczych przy pomocy zlecenia typu Search. W tym elemencie podaje się kryteria wyszukiwania informacji, które determinują typ informacji jakich system będzie szukał. Można wyszukiwać wg numeru NIP (informacje o niespełnionych zobowiazaniach przedsiębiorców) lub PESEL (informacje o spełnionych i niespełnionych zobowiązaniach konsumentów). Do wyszukiwania informacji o zobowiązaniach powstałych przed wejściem w życie ustawy o Buirach Informacji Gospodarczej, potrzebne jest upoważnienie przedsiębiorcy bądź konumenta, którego dane chcemy wyszukać. Dodatkowo wyszukiwanie informacji o konumentach możliwe jest tylko po uszyskaniu stosownego upoważnienia (nie potrzebują go tylko instytucje takie jak NIK czy prokuratura). Informacje o posiadaniu takich upoważnien deklaruje klient podając datę uzyskania takiego upoważnienia. Upoważnienia te ważne są przez 30 dni. Raport z informacjami gospodarczymi spełniajacymi wymogi klienta jest zapamiętywany w systemie i jest dostępny dla klienta także w późniejszym czasie (w ograniczonym zakresie, aktualnie w ciągu 24 godzin od jego Opracowanie wewnętrzne Strona 17 z 91 Copyright Krajowy Rejestr Długów, 2014

18 wygenerowania). Klient może pobrać listę swoich raportów z informacjami zlecając zadanie GetDisclosureReports lub obejrzeć szczegóły konkretnego raportu przy pomocy zlecenia GetDisclosureReport. Jeżeli w raporcie z systemu KRD znajdą się informacje gospodarcze niezgodne ze schematem protokołu, a będące w zakresie minimalnych danych wymaganych przez ustawę (np. identyfikator podatkowy inny niż NIP), system zwróci informację o błędzie i nie wygeneruje w transzy wynikowej raportu. Jeżeli wygenerowany raport zawiera informacje wykraczające poza zakres wymagany, ale niezgodne ze schematem protokołu (np. adres korespondencyjny dłużnika będącego konsumentem) w transzy wynikowej pojawi się w atrybut hastruncatedinformations. Oznacza on, że raport zawiera dodatkowe informacje, których nie da się przekazać za pomocą transzy NICCI 2.1 Tego typu raporty można pobrać w pełnej formie tylko poprzez stronę WWW Zlecenia dotyczące monitorowania Biuro umożliwia klientom monitorowanie zdarzeń, które powiązane są z odpowiednimi numerami NIP. Monitoring polega na tym, że gdy ktokolwiek wykona pewną operacją związaną z monitorowanym NIP, to klient monitorujący zostanie o tym powiadomiony. Sposób powiadomienia wybiera sam klient i może to ono zrealizowane poprzez wysłanie a na odpowiedni adres, badź poprzez umieszczenie odpowiedniej informacji w serwiscie klienta na stronie www. Dodawanie oraz aktualizację warunków monitorowania wykonuje się przy pomocy zleceń opisanych elemrntami, odpowiednio AddMonitorCondition oraz UpdateMonitorCondition. W każdej chwili można zatrzymać dalsze monitorowanie poprzez StopMonitorCondition. Klient ma także możliwość usuwania wprowadzonych przez siebie warunków monitorowania przy pomocy zlecenia RemoveMonitorCondition. Usunięcie można zlecić z przyszłą datą. Listę dodanych przez siebie warunków monitora klient może pozyskać zlecając zadanie GetMonitorConditions. Do pobrania listy zdarzeń z systemu służy element CheckEvents. W odpowiedzi otrzymujemy listę zdarzeń wygenerowanych przez system na podstawie aktywnych warunków monitorowania. Lista taka zawiera tylko zdarzenia z dnia poprzedniego Zlecenia nie wspierane przez wersję 2.1 Istnieje grupa zleceń, które nie są obsługiwane przez system. Należą do nich wspomniane już zlecenia dotyczące informacji gospodarczych o spełnionych zobowiązaniach czy o posłużeniu się cudzym lub podrobionym dokumentem oraz zlecenia CaseValidationEvents i InformationValidationEvents dotyczące weryfikaji przekazanych danych. Pełna lista zleceń nie obsługiwanych przez wersję 2.1: AddInformation UpdateInformation RemoveInformation SuspendInformation Opracowanie wewnętrzne Strona 18 z 91 Copyright Krajowy Rejestr Długów, 2014

19 UnsuspendInformation ChangeInformationowner GetInformations CaseValidationEvents InformationValidationEvents SearchRegistry Opracowanie wewnętrzne Strona 19 z 91 Copyright Krajowy Rejestr Długów, 2014

20 3. Opis schematu XML W tej części dokumentu opisane zostaną elementy składowe plików XSD, które składają się na definicję schematu XML plików wymiany danych. W punkcie 3.1 opisane są typy oraz grupy wykorzystywane w trakcie wymiany danych. Punkt 3.2 zawiera opis definicji pliku ze zleceniami do wykonania, który klienci przesyłają do biura. Definicja odpowiedzi, którą biuro wysyła do klientów opisana jest w punkcie Plik niccicommon.xsd Plik zawiera definicje typów podswtaowych oraz wszystkich elementów, które są wspólne zarówno dla pliku wejściowego jaki i pliku z odpowiedzią Typy proste Typy proste definiują wymagania stawiane pojedynczym wartościom, takim jak numer NIP czy data. Wymagania te obejmują minimalną i maksymalną długość wartości, jak też jej formatu. Format ten jest opisany za pomocą wyrażeń regularnych (regular expresions, regex ), których opis wykracza poza zakres tego dokumentu Typ nonemptystring <xs:simpletype name="nonemptystring"> <xs:restriction base="xs:string"> <xs:minlength value="1"/> </xs:restriction> </xs:simpletype> Typ oznaczający niepusty łańcuch znaków Typy nonemptystringxxx <xs:simpletype name="nonemptystring16"> <xs:restriction base="nonemptystring"> <xs:maxlength value="16"/> </xs:restriction> </xs:simpletype> Typy oznaczające niepusty łańcuch znaków o określonej maksymalnej długości Typ datetype <xs:simpletype name="datetype"> <xs:restriction base="xs:date"> <xs:pattern value="\d{4}-\d{2}-\d{2}"/> </xs:restriction> </xs:simpletype> Elementy tego typu zawierają datę w formacie yyyy-mm-dd. Opracowanie wewnętrzne Strona 20 z 91 Copyright Krajowy Rejestr Długów, 2014

21 Typ guidtype <xs:simpletype name="guidtype"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9a-fa-f]{8}-[0-9a-fa-f]{4}-[0-9a-fa-f]{4}-[0-9afa-f]{4}-[0-9a-fa-f]{12}"/> </xs:restriction> </xs:simpletype> Elementy tego typu zawierają unikalny identyfikator GUID Typ orderidtype <xs:simpletype name="orderidtype"> <xs:restriction base="nonemptystring128"/> </xs:simpletype> Elementy tego typu zwierają unikalny identyfikator zadania zlecanego przez klenta do biura. Typ jest zgodny z nonemptystring Typ loginnametype <xs:simpletype name="loginnametype"> <xs:restriction base="nonemptystring256"/> </xs:simpletype> Elementy tego typu zawierają identyfikator użytkownika systemu. Pod względem wartości typ jest zgodny z typem nonemptystring Typ peseltype <xs:simpletype name="peseltype"> <xs:restriction base="xs:string"> <xs:pattern value="\d{11}"/> </xs:restriction> </xs:simpletype> Elementy tego typu zawierają numer Pesel. Wartość tego numeru nie jest sprawdzana pod względem poprawności (poza stwierdzeniem, że składa się z samych cyfr), a jedynie pod względem długości Typ niptype <xs:simpletype name="niptype"> <xs:restriction base="xs:string"> <xs:pattern value="[\d-]{10,13}"/> </xs:restriction> </xs:simpletype> Elementy tego typu zawierają numer NIP. Wartość tego numeru nie jest sprawdzana pod względem poprawności, a jedynie pod względem długości oraz formatu. Numer NIP można zapisać w wersji z kreskami lub bez. Opracowanie wewnętrzne Strona 21 z 91 Copyright Krajowy Rejestr Długów, 2014

22 Typ regontype <xs:simpletype name="regontype"> <xs:restriction base="xs:string"> <xs:pattern value="\d{9}"/> </xs:restriction> </xs:simpletype> Elementy tego typu zawierają numer Regon. Wartość tego numeru nie jest sprawdzana pod względem poprawności, a jedynie pod względem długości Typ ekdtype <xs:simpletype name="ekdtype"> <xs:restriction base="xs:string"> <xs:pattern value="\d[\d\.]*"/> </xs:restriction> </xs:simpletype> Elementy tego typu zawierają numer EKD (Europejska Klasyfikacja Działalności). Numer EKD musi składać się, z co najmniej jednej cyfry. Poszczególne cyfry mogą być rozdzielone kropką Typ decimaltype <xs:simpletype name="decimaltype"> <xs:restriction base="xs:decimal"> <xs:pattern value="-?\d+[.]?\d*"/> </xs:restriction> </xs:simpletype> Elementy tego typu zawierają liczbę zmiennoprzecinkową, w której część ułamkowa (o ile istnieje) jest oddzielona kropką. Dodatkowo liczba może być poprzedzona znakiem (kod Ascii 45) Typ type <xs:simpletype name=" type"> <xs:restriction base="xs:string"> <xs:maxlength value="64"/> <xs:pattern value="[a-za-z0-9][-_a-za-z0-9\.]+@[-_a-za-z0-9\.]*[a-za- Z]"/> </xs:restriction> </xs:simpletype> Elementy tego typu zawierają adres Typ phonenumbertype <xs:simpletype name="phonenumbertype"> <xs:restriction base="xs:string"> <xs:maxlength value="32"/> <xs:pattern value="(\+\d+)?(\(\d+\))?[\d -]*"/> Opracowanie wewnętrzne Strona 22 z 91 Copyright Krajowy Rejestr Długów, 2014

23 </xs:restriction> </xs:simpletype> Elementy tego typu zawierają numer telefonu Typ versiontype <xs:simpletype name="versiontype"> <xs:restriction base="xs:string"> <xs:pattern value="2\.1"/> </xs:restriction> </xs:simpletype> Typ służy do określenia wersji typu schematu xml. W tej wersji dokumentu dozwolona jest jedynie wartość Typ currencytype <xs:simpletype name="currencytype"> <xs:restriction base="xs:string"> <xs:pattern value="[a-za-z]{3}"/> </xs:restriction> </xs:simpletype> Typ słuzy do określenia rodzaju waluty będącego trzyliterowym skrótem Typ monitornotificationtypeenum <xs:simpletype name="monitornotificationtypeenum"> <xs:restriction base="xs:integer"> <xs:enumeration value="mnnoone"/> <xs:enumeration value="mnowner"/> <xs:enumeration value="mnmainuser"/> <xs:enumeration value="mnallusers"/> </xs:restriction> </xs:simpletype> Elementy tego typu zawierają informację o tym, na jaki adres ma zostać przekazana informacja o zaistnieniu zdarzenia śledzonego przez monitor. Element może przyjmować tylko jedną z dopuszczalnych wartości: - mnnoone ma nie być w ogóle wysyłany, - mnowner wysyłka tylko do właściciela monitora, - mnmainuser wysyłka na główny firmy, - mnallusers wysyłka na wszystkie emalie firmy Typy złożone Typy złożone definują struktury danych, składających się z więcej niż jednego elementu. Określają one wymaganą krotność oraz typ bądź format elementów składowych. Opracowanie wewnętrzne Strona 23 z 91 Copyright Krajowy Rejestr Długów, 2014

24 Typ headertype <xs:complextype name="headertype"> <xs:element name="date" type="datetype"/> <xs:element name="number" type="xs:positiveinteger"/> <xs:element name="clientid" type="guidtype"/> <xs:element name="category" type="nonemptystring256" minoccurs="0"/> <xs:element name="generator" type="nonemptystring256" minoccurs="0"/> <xs:element name="version" type="versiontype"/> Typ służy do definiowana nagłówka w plikach wymienianych pomiędzy klientem a biurem. Typ składa się z następującej sekwencji elementów: - Date - typu datetype zawierający datę przygotowania pliku, - Number - będący całkowitą liczbą dodatnią oznaczającą numer kolejnej transzy danych, - ClientID - typu guidtype określający identyfikator klienta, od którego jest plik, bądź do którego wysyłany jest raport. - Category typu nonemptystring256, który zawiera dowolną informację dodatkowo opisującą transzę. Znaczenie tego elementu jest ustalane z każdym klientem osobno. Element może być pominiety. - Generator typu nonemptystring256 zawierający nazwę programu, który posłużył do wygenerowania transzy XML. Element może być pominięty. - Version - typu versiontype określający wersję pliku schematu. Przykład 3-1 Typ headertype <Header> <Date> </Date> <Number>1222</Number> <Client> ABCD AB</Client> <Category>Kategoria1</Category> <Generator>XMLScript Generator 1.0</Generator> <Version>2.1</Version> </Header> Typ moneytype <xs:complextype name="moneytype"> <xs:element name="amount" type="decimaltype"/> <xs:element name="currency" type="currencytype" default="pln" minoccurs="0"/> Typ służy do definiowania elementów zawierających kwotę pieniędzy. Składa się z dwóch elementów: - Amount typu decimaltype będący wysokością kwoty. Pole jest wymagane, Opracowanie wewnętrzne Strona 24 z 91 Copyright Krajowy Rejestr Długów, 2014

25 - Currency typu currencytype będący typem waluty. Prawidłową wartością jest ciąg składający się z trzech liter (wielkich lub małych). Podanie kodu waluty nie jest obowiązkowe i w takim przypadku domyślnie przyjmowana jest wartość PLN. Element zawierający kwotę pokazany jest w przykładzie 3-1. Przykład 3-2 Elementy Debt typu moneytype <Debt> <Amount>100</Amount> <Currency>Eur</Currency> </Debt> Typ propertiestype <xs:complextype name="propertiestype"> <xs:element name="property" maxoccurs="unbounded"> <xs:complextype> <xs:group ref="propertygroup"/> </xs:element> Element tego typu zawiera, co najmniej jeden element Property typu propertytype zawierający w sobie element typu propertygroup. Element jest kolekcją dodatkowych właściwości pewnych obiektów Typ addresstype <xs:complextype name="addresstype"> <xs:choice> <xs:choice> <xs:element name="city" type="nonemptystring32"/> <xs:group ref="streetgroup" minoccurs="0"/> <xs:group ref="streetgroup"/> </xs:choice> <xs:element name="building" type="nonemptystring16" minoccurs="0"/> <xs:element name="flat" type="nonemptystring16" minoccurs="0"/> <xs:element name="zipcode" type="nonemptystring16"/> <xs:element name="post" type="nonemptystring32"/> <xs:element name="country" type="nonemptystring128" minoccurs="0"/> <xs:element name="description" type="nonemptystring256" minoccurs="0"/> <xs:element name="postscript" type="nonemptystring128" minoccurs="0"/> Opracowanie wewnętrzne Strona 25 z 91 Copyright Krajowy Rejestr Długów, 2014

26 <xs:element name="line" type="nonemptystring128" minoccurs="2" maxoccurs="4"/> </xs:choice> Element tego typu zawiera dane o adresie. Adres można podać na dwa sposoby. Pierwszy to wymienienie kolejno wszystkich niezbędnych składników adresu, drugi to podanie adres w postaci linii tekstu. W pierwszym przypadku element typu addresstype składa się z sekwencji nastepujących elementów: - City i elementu grupy streetgroup jeżeli element City będzie podany, to elementy z grupy streetgroup nie są wymagane. W przypadku gdy podamy element grupy streetgroup, to nie jest wymagany element City, - Building numer budynku. Element może być pominięty, - Flat numer mieszkania. Element może być pominięty, - ZipCode kod pocztowy. Element obowiązkowy, - Post nazwa poczty. Element obowiązkowy. - Country nazwa kraju. Element może być pominięty, - Description dodatkowy opis adresu. Element może być pominięty, - Postscript dopisek w adresie. Element może być pominięty. W przypadku, gdy adres podawany jest w postaci linii, to element addresstype składa się z sekwencji elementów Line. Są to niepuste łańcuchy znaków. Elementy Line muszą wystąpić 2 do 4 razy. Wszystkie powyższe elementy to niepuste ciągi znaków. W przykładzie 3-3 pokazany jest zformalizowany opis adresu, a w przykładzie 3-4 użyty jest format złożony z kolejnych linii. Przykład 3-3 Typ addresstype format rozszerzony <Address> <City>Kozia Wólka</City> <StreetPrefix>Al.</StreetPrefix> <Street>Wojska Polskiego</Street> <Building>1b</Building> <Flat>22</Flat> <ZipCode>00-200</ZipCode> <Post>Radom</Post> <Country>Polska</Country> <Postscript>dla Pani Zosi</Postscript> </Address> Przykład 3-4 Typ addresstype format prosty <SeatAddress> <Line>ul. Kolejowa 11-13</Line> <Line> Warszawa</Line> </SeatAddress> Opracowanie wewnętrzne Strona 26 z 91 Copyright Krajowy Rejestr Długów, 2014

27 Typ personstype <xs:complextype name="personstype"> <xs:element name="person" maxoccurs="unbounded"> <xs:complextype> <xs:element name="firstname" type="nonemptystring32"/> <xs:element name="secondname" type="nonemptystring32" minoccurs="0"/> <xs:element name="surname" type="nonemptystring64"/> <xs:element name="role" type="string32" minoccurs="0"/> </xs:element> Element tego typu służy o osobach związanych z dłużnikiem (np.: pełnomocnicy, prokurenci). Typ ten składa się z listy złożonej, z co najmniej jednego elementu Person, który z kolei zawiera sekwencję czterech elementów FirstName, SecondName, Surname oraz Role. Są to łańcuchy znaków zawierające kolejno imię, drugie imię i nazwisko osoby (drugie imie i rola jest elementem niewymagalnym pozostałe tak) oraz nazwę roli w jakiej występuje ta osoba (element może być pominięty). Drugie imię i nazwa roli mogą pozostać puste. Przykład 3-5 Typ personstype <Person> <FirstName>Jan</FirstName> <SecondName>Maria</SecondName> <Surname>Kowalski</Surname> <Role>pełnomocnik</Role> </Person> <Person> <FirstName>Jan</FirstName> <Surname>Kowalski</Surname> </Person> </Persons> Typ stakeholderstype <xs:complextype name="stakeholderstype"> <xs:element name="stakeholder" maxoccurs="unbounded"> <xs:complextype> <xs:group ref="nonrequiredlegalpersondatagroup"/> <xs:group ref="nonrequiredconsumerdatagroup"/> </xs:element> Opracowanie wewnętrzne Strona 27 z 91 Copyright Krajowy Rejestr Długów, 2014

28 Element tego typu służy do przechowywania danych o wspólnikach, pełnomocnikach, współakcjonariuszach, itp. dłużnika. Typ ten składa się z listy złożonej, z co najmniej jednego elementu Stakeholder, który może zawierać elementy z dwóch grup: 1. nonrequiredlegalpersontype w celu przekazania danych o firmie wspólnika, 2. nonrequiredconsumergroup w celu przekazania danych o wspólniku jako osobie fizycznej. Przykład 3-6 Typ stakeholderstype <Stakeholders> <Stakeholder> <Name>FirmaPol</Name> <Nip> </Nip> <Regon> </Regon> <RegistrationNumber>20/a/2003</RegistrationNumber> <RegistryName>Rejestr sądowy</registryname> <Ekd>00</Ekd> <SeatAddress> <City>Wrocław</City> <StreetPrefix>pl.</StreetPrefix> <Street>Grunwaldzki</Street> <Building>45</Building> <Flat>16</Flat> <ZipCode>56300</ZipCode> <Post>Wrocław</Post> <Country>Polska</Country> </SeatAddress> <Persons> <Person> <FirstName>Jan</FirstName> <SecondName>Maria</SecondName> <Surname>Kowalski</Surname> <Role>pełnomocnik</Role> </Person> </Persons> <FirstName>Adam</FirstName> <SecondName>Jan</SecondName> <Surname>Przykladowy</Surname> <Citizenship>polskie</Citizenship> <Address> <City>Tczew</City> <StreetPrefix>ul.</StreetPrefix> <Street>Przejazdowa</Street> <Building>8</Building> <Flat>4</Flat> <ZipCode>21200</ZipCode> <Post>Tczew</Post> <Country>Polska</Country> </Address> <Birthday> </Birthday> <Pesel> </Pesel> </Stakeholder> </Stakeholders> Opracowanie wewnętrzne Strona 28 z 91 Copyright Krajowy Rejestr Długów, 2014