Z punktu widzenia G2I te dwie operacje są od siebie niezależne. Zarówno Zbywca jak i Nabywca mogą być klientem Big Consulting Sp. z o.o. Sprzedaż Oper

Wielkość: px

Rozpocząć pokaz od strony:

Download "Z punktu widzenia G2I te dwie operacje są od siebie niezależne. Zarówno Zbywca jak i Nabywca mogą być klientem Big Consulting Sp. z o.o. Sprzedaż Oper"

Patrycja Górecka
6 lat temu
Przeglądów:

1 Temat: Własność: Wersja: Zasada działania systemu Gate-To-Information Przekazywanie Big Consulting Sp. z o.o. 1.3.xx Aktualizacje: Uaktualnienie zgodnie ze zmianami w funkcjonowaniu rejestru Branżowa Informacja Kredytowa Aktualizacja opisu Dodanie opisu wymagalności pól Dodanie opisu identyfikatorów Dodanie możliwości przekazywania Tytułu wykonawczego v1.02 Dodanie obsługi zakupu i sprzedaży wierzytelności Zakres dokumentu Niniejszy dokument opisuje zasadę działania systemu przekazywania danych do wybranych źródeł informacji o stanie zadłużenia dłużników (zobowiązania). Przekazywanie następuje w oparciu o przygotowywane pliki wsadów zawierające aktualny stan zobowiązań dłużników podlegających przekazaniu. 1. Ogólna zasada działania Stan zobowiązań jest to lista wszystkich zobowiązań kontrahentów (konsumentów) jakie mają być przekazane do źródła (źródeł). Plik taki jest przygotowywany periodycznie i zawiera zawsze aktualny stan zobowiązań. Oznacza to, że system IT Klienta nie analizuje co i kiedy było już przekazane. Analiza taka wykonywana jest zawsze przez system G2I. Jej wynikiem jest lista operacji jakie będą wykonane w odniesieniu do każdego źródła i każdego zobowiązania. Aktualnie obsługiwane źródła: Krajowy Rejestr Długów BIG S.A. BIG InfoMonitor S.A. Rejestr Dłużników ERIF S.A. Rodzaj przekazywanych informacji: niespłacone zobowiązanie w rozumieniu UoUIG (art. 14 i 15) zobowiązania alimentacyjne UoUIG (art. 16 u.5) zobowiązania stwierdzone tytułem wykonawczym UoUIG (art. 16 u.1) Sprzedaż i zakup portfela wierzytelności (zobowiązań) Operacja sprzedaży i zakupu partii wierzytelności pozwala na implementację prawnej możliwości jaką daje Art. 29 p. 3 i 4 UoUIG czyli zbycia i zakupu wierzytelności.

Z punktu widzenia G2I te dwie operacje są od siebie niezależne. Zarówno Zbywca jak i Nabywca mogą być klientem Big Consulting Sp. z o.o. Sprzedaż Operacja zbycia wierzytelności może dotyczyć całości lub części pakietu wierzytelności wcześniej przekazanego do BIG.

Lista sprzedanych wierzytelności zawarta jest w strukturze XML: Zakup Operacja zakupy wierzytelności może dotyczyć wszystkich lub wybranych tylko BIGów.

2 Z punktu widzenia G2I te dwie operacje są od siebie niezależne. Zarówno Zbywca jak i Nabywca mogą być klientem Big Consulting Sp. z o.o. Sprzedaż Operacja zbycia wierzytelności może dotyczyć całości lub części pakietu wierzytelności wcześniej przekazanego do BIG. Również może dotyczyć wszystkich lub wybranych tylko BIGów. Lista sprzedanych wierzytelności zawarta jest w strukturze XML: Zakup Operacja zakupy wierzytelności może dotyczyć wszystkich lub wybranych tylko BIGów. Zakupione wierzytelności wprowadzane są na stan w G2I bez wykonywania operacji w stosunku do BIG. Lista zakupionych wierzytelności opisana jest w sposób identyczny jak w przypadku zwykłego przekazywania czyli w strukturze: Jednak w zestawie parametrów w sekcji <Parameters> pojawi się nowy Tag o zawartości Tak.

Plik zawiera zakup wierzytelności Zarówno Sprzedaż jak i Zakup wierzytelności wymagają działań odpowiednio Zbywcy i Nabywcy w stosunku do BIG niezależnie od operacji wykonanych w G2I.

3 Plik zawiera zakup wierzytelności Zarówno Sprzedaż jak i Zakup wierzytelności wymagają działań odpowiednio Zbywcy i Nabywcy w stosunku do BIG niezależnie od operacji wykonanych w G2I. Są to działania wymiennie w Art. 29 p. 3 i 4 UoUIG. Harmonogram przekazywania danych System Gate-To-Information przyjmuje dane do przekazania w dowolnym cyklu. Jednak ze względu na wymogi UoUIG konieczne jest aktualizowanie wcześniej przesłanych danych nie później niż po 14 dniach od zmiany w tych danych. Z tego powodu rekomendujemy przesyłanie wsadów w cyklu 7-dniowym co zapewni dużą świeżość danych oraz duży margines bezpieczeństwa. W przypadku rejestrów branżowych cykl przekazywania danych zależy od wewnętrznych ustaleń grupy przedsiębiorstw. 2. Algorytm procesu przekazywania danych A. Przygotowanie danych a. system Klienta rozliczający płatności przygotowuje plik w postaci XML z listą wszystkich zobowiązań jakie mają zostać przekazane do źródeł. b. Plik ten zawiera: - dane dłużnika - dane o długu (zobowiązaniu)

4 c. Plik z wsadem nie zawiera - danych o Kliencie (wierzycielu). Dane te pobierane są z systemu Gate-To-Information - informacji, do których źródeł dane mają być przekazane. Przeznaczenie danych określane jest w systemie Gate-To-Information podczas wczytywania danych. d. Przez zobowiązanie można rozumieć jedną z trzech opcji: - poszczególne faktury - umowa z klientem przy kontraktach ciągłych (leasing, sprzedaż ratalna, kredyt bankowy) - saldo zadłużenia klienta Ważne jest aby raz przyjęty system nie uległ późniejszej zmianie. B. Wybór źródeł W opcji Import/Przekazanie zobowiązań w systemie Gate-To-Information uprawniony operator dokonuje wyboru do jakich źródeł mają trafić wczytywane dane. Wyboru dokonuje poprzez wybór Profilu przekazania. Profil przekazania jest listą źródeł. W skrajnym przypadku profil zawiera jedno źródło lub wszystkie źródła dostępne dla Klienta. C. Wczytanie pliku a. Operator wskazuje plik, który zawiera stan zobowiązań do przekazania. b. Plik podlega kontroli na zgodność: - składniową zgodnie z definicją XSD - spójności i wymagalności danych - zgodności przekazanych danych z wymaganiami źródeł c. W przypadku stwierdzenia błędów: - generowany jest raport - cały plik jest odrzucany d. W przypadku gdy dane są poprawne - system G2I pyta o potwierdzenie operacji - następuje wczytanie poszczególnych zobowiązań - dla każdego zobowiązania i każdego wybranego źródła program generuje poszczególne operacje do wykonania. System G2I analizuje otrzymaną partię danych pod kątem wykrycia jednej z trzech możliwych sytuacji w stosunku do każdego wybranego źródła. Nowe zobowiązanie w danym źródle nie było dotychczasowego przekazania danego zobowiązania. Aktualizacja dane zobowiązanie jest już przekazane do źródła i wymaga aktualizacji. Usunięcie - wcześniej przekazano zobowiązanie do źródła ale a w bieżącej partii danych już go nie ma.

5 - programy komunikacyjne rozpoczynają wykonywanie operacji w poszczególnych źródłach Identyfikatorem zobowiązania, na podstawie którego dokonywana jest identyfikacja zobowiązania jest zawartość taga: <AddCases><AddCase><Case><CaseObligations><CaseObligation><IDProperty> D. Wynik przekazania Operator systemu będzie miał możliwość przeglądania: a. Niepoprawnie wykonanych operacji przekazania b. Listy zobowiązań w danym źródle c. Listy zobowiązań wybranego kontrahenta W systemie Gate-To-Information nie ma możliwości zmiany danych zobowiązania. Założenie to wynika z faktu, że jeżeli operacja taka byłaby możliwa to wówczas istnieje bardzo duże ryzyko rozsynchronizowania danych w systemie Klienta z danymi w G2I a co za tym idzie w źródle. E. Identyfikacja zlecenia a identyfikacja zobowiązania Identyfikator (numer referencyjny) zlecenia Przekazując plik z danymi każde zlecenie ma nadane przez system Klienta numer referencyjny. Po tym numerze następuje komunikacja pomiędzy systemem Klienta a systemem G2I. Numer referencyjny umieszczony jest w tagu: <AddCases><AddCase><Case><ID> Numer ten może być dowolny byle był unikalny w skali jednego pliku. Nie ma konieczności zachowania zgodności numerów pomiędzy kolejnymi plikami. Dodatkowy numer referencyjny Numer referencyjny zlecenia może być również umieszczony w <AddCases><AddCase><OrderID>. Jest on wykorzystywany do zwrotnej komunikacji w przypadku błędów wstawienia opisu dłużnika lub zobowiązania do systemu G2I. Identyfikator zobowiązania. Identyfikator ten jest unikalnym i niezmiennym identyfikatorem danego zobowiązania z w systemie Klienta. Może to być unikalny numer faktury, numer klienta (w przypadku przekazywania zobowiązań saldem). Na podstawie tego identyfikatora następuję podjęcie decyzji przez system G2I czy należy dokonać - dodania nowego zobowiązania - usunięcie zobowiązania - aktualizacji - brak konieczności wykonania operacji. Identyfikator zobowiązania umieszczony jest w tagu:

6 <AddCases><AddCase><Case><CaseObligations><CaseObligation><IDProperty> W systemie G2I istnieją jeszcze identyfikatory: ID zobowiązania <AddCases><AddCase><Case><CaseObligations><CaseObligation><ID> oraz <AddCases><AddCase><Case><CaseObligations><CaseObligation><IDZobowiazania> Zawartość tych pól jest wykorzystywana do celów wewnętrznych systemów G2I. F. Tytuły wykonawcze System G2I umożliwia przekazywanie danych o tytułach wykonawczych zgodnie z Art. 16 u.1. UOUiG. Dane o tytule wykonawczym przekazywane są w tagu: <AddCases><AddCase><Case><CaseObligations><CaseObligation><ExtraInformations> <ExecuteTitle> Informacja ta składa się z pięciu części: <ExecuteTitleSignature> - sygnatura sprawy <ExecuteTitleKind> - tytuł prawny do Tytułu wykonawczego. Tylko InfoMonitor. <ExecuteTitleType> - rodzaj zdarzenia. Tylko ERIF. <ExecuteAuthorityData> - oznaczenie organu orzekającego <ExecuteIssueDate> - data wydania tytułu wykonawczego. Ze względu na różne rozwiązania przyjęte przez poszczególne BIGi drugi i trzeci tag jest dedykowany jedynie dla specyficznego BIGu tj. odpowiednio InfoMonitor i ERIF. Szczegóły wymagalności opisano niżej w tabeli. 3. Składnia plików wymiany Poniższe pliki zawierają niezbędne informacje do przygotowania pliku wsadu do przekazania do źródeł. G2I_All.XSD składnia budowy plików XML. Element: <AddCase> przykłady przykłady plików z danymi do przekazania. Interfejs_G2I_Online.pdf - opis mechanizmów komunikacji w trybie G2I_online Powyższe pliki dostępne są na stronie z opisem technicznym systemu G2I.

Podobne dokumenty

Załącznik nr 4 do Załącznika nr 1 do SIWZ. Scenariusze testowe dla obszaru budżetowo-księgowego

Załącznik nr 4 do Załącznika nr 1 do SIWZ Scenariusze testowe dla obszaru budżetowo-księgowego Założenia: W momencie przystąpienia do testów System powinien zawierać wprowadzone wcześniej dane: plan finansowy