Opis zmian Interfejsu ZSD3 które zostaną wdrożone do końca 2014 roku. SAP-SD3 wersja dla: BGK@24Biznes str. 1
Opis funkcjonalny zmian do interfejsu ZSD3 Uwaga! Na rachunkach sum depozytowych podlegających konsolidacji występuje poniższa sytuacja: - saldo na rachunku zbiorczym będzie równe 0 (słownie: zero) po konsolidacji (na koniec dnia), natomiast na raporcie sum depozytowych będą niezerowe stany odpowiadające saldu podlegającemu konsolidacji (salda mikrorachunków w ujęciu informacyjnym nie zmieniają się w chwili procesu konsolidacji), - następnego dnia roboczego po konsolidacji nastąpi powrót środków na rachunek zbiorczy (dekonsolidacja) odsetki za dany dzień naliczą się na mikrorachunku (zmiana w polu odsetki bieżące z punktu widzenia mikrorachunku sposób przechowywania i prezentowania informacji o odsetkach bieżących nie ulega zmianie). Podsumowanie: Konsolidacja SDS dotyczy wyłącznie sald rachunków bilansowych (głównych). Rachunki ewidencyjne poszczególnych SD (mikrorachunki) nie są konsolidowane. Poniższe pozycje występujące na wyciągu z rachunku Ministra Finansów powinny być pomijane w procesie wczytywania wyciągu do interfejsu ZSD3. Treść pozycji na wyciągu BO.kons.przeks.k Konsolid. nr: n Zwrot po kons. BO dla rach.sds Opis pozycji Księgowanie syntetyczne dot. przeksięgowania migrowanego salda, które występuje na rachunku komercyjnym po stronie D (obciążenie) oraz na rachunku MF Sądu po stronie C (uznanie) Księgowanie na koniec danego dnia roboczego konsolidacja salda gdzie n oznacza kolejną iterację księgowania - po stronie D (obciążenie) Księgowanie na początek następnego dnia roboczego dekonsolidacja salda - po stronie C (uznanie) Księgowania z Bilansu Otwarcia na rachunkach MF Zakres zmian w interfejsie: SD3_1. Dodanie globalnego parametru, który będzie sterował logiką funkcjonowania interfejsu konsolidacja FPII (domyślnie parametr ustawiony na NIE/ wyłączona obsługa KFPII). SD3_2. Dodanie możliwości sparametryzowania rachunków sum depozytowych MF w tabeli ZSD3TA_RACH_BANK. SD3_3. W okresie przejściowym i w scenariuszu docelowym mogą funkcjonować 2 rachunki sum depozytowych (dla danej waluty w danym Sądzie), tj. na dwóch różnych klientach (1/ Sąd XXXX MF sumy podlegające konsolidacji, 2/ Sąd XXXX - sumy nie podlegające konsolidacji). W tym celu powinien być stworzony mechanizm w interfejsie SAP, który będzie umożliwiał wgranie do SAP dwóch wyciągów oraz dwóch raportów sum depozytowych zarządzanych str. 2
przez ten sam Sąd po jednym zestawie z dwóch różnych klientów (sytuacja występuje dla każdej waluty obsługiwanej w ramach SDS). Zakłada się, że w zakresie sum depozytowych, które nie będą podlegać konsolidacji, Sąd może być obsługiwany przez inny bank (np. Citibank, mbank). Raport sum depozytowych oraz wyciąg klienta podlegającego konsolidacji (Sąd XXXX MF) będzie posiadał w nazwie pliku prefix w postaci NRB informujący jakiego rachunku dotyczy dany wyciąg/ raport sum depozytowych (w obecnej funkcjonalności oraz dla klientów niepodlegających konsolidacji (Sąd XXXX) informacja dot. numeru rachunku zbiorczego zawarta jest w samym pliku dane merytoryczne pliku a nazwa pliku nie zawiera prefixu wskazującego NRB). SD3_4. W związku z dodaniem na Raporcie sum depozytowych (RSD z systemu BGK@24BIZNES) nowych pól zawierających informacje o: Sektor/Podsektor, Poprzedni rachunek (mikrorachunek). należy rozszerzyć funkcjonalność interfejsu, aby mogłyby być czytane nowe informacje wskazane powyżej. Nowe informacje przenoszone są za pomocą dodatkowych tagów, które występują w RSD na końcu zestawu danych dot. danej sumy depozytowej. Tagi: <SEKTOR_KOD>Kod sektora/podsektora sumy depozytowej</ SEKTOR_KOD> <SEKTOR_OPIS>Opis sektora/podsektora</ SEKTOR_OPIS> będą dostępne w RSD tylko dla mikrorachunków, dla których informacja o sektorze/podsektorze nie jest pusta. Mikrorachunki dla których sektor/podsektor nie został uzupełniony nie będą posiadały w RSD wskazanych dwóch dodatkowych tagów. Tag: <POPRZEDNI_RACHUNEK>NRB poprzedniego rachunku sumy depozytowej</poprzedni_rachunek> będzie występował dla klientów, którzy będą migrowali się na rachunki MF i będą w momencie migracji na rachunki MF klientami BGK; nowe wpłaty oraz depozyty na rachunkach MF, zmigrowane z innego Banku niż BGK, nie będą posiadały tagu <POPRZEDNI_RACHUNEK>. Przykład fragmentu pliku RSD z nowymi tagami poniżej: <SUMA_DEP> <SUMA_DEP num="43"> <ID>437137</ID> <LP>241-9-130219</LP> <ID_AN_DEF>55652</ID_AN_DEF> <SYGNATURA>Shpek Nadiya RKS 818/2013</SYGNATURA> <TYPPODMIOTU>1</TYPPODMIOTU> <SALDO>0.2</SALDO> <STATUS>1</STATUS> str. 3
<RACHUNEK>15 1130 1105 7005 2162 3300 0278</RACHUNEK> <WALUTA>PLN</WALUTA> <NR_KOLEJNY>7005216233</NR_KOLEJNY> <KAPITAL>200</KAPITAL> <ODS_NAL_BO>0</ODS_NAL_BO> <ODSETKI_SK_NAL_BO>0.2</ODSETKI_SK_NAL_BO> <ODS_KAP>0</ODS_KAP> <ODSETKI>0</ODSETKI> <DEPOZYT_DATA>2013-10-08</DEPOZYT_DATA> <OBC_DEPOZYT>200</OBC_DEPOZYT> <RACHUNEK_SDS>19 1130 1105 0005 2162 3390 0002</RACHUNEK_SDS> <DATA_DANYCH>2014-09-11</DATA_DANYCH> <TYTUL_PIERWSZEGO_PRZELEWU_1><PPDE\400000\2013\1533></TYTUL_PIERWSZEG O_PRZELEWU_1> <TYTUL_PIERWSZEGO_PRZELEWU_2>Zabezpieczenie kary grzywny dot.</tytul_pierwszego_przelewu_2> <TYTUL_PIERWSZEGO_PRZELEWU_3>SHPEK NADIYA RKS 818/2013/404000/A</TYTUL_PIERWSZEGO_PRZELEWU_3> <TYTUL_PIERWSZEGO_PRZELEWU_4>S</TYTUL_PIERWSZEGO_PRZELEWU_4> <DANE_DODATKOWE_1>IZBA CELNA W PRZEMY LU37-700 Przemy</DANE_DODATKOWE_1> <DANE_DODATKOWE_2>lSIELECKA 9</DANE_DODATKOWE_2> <DANE_DODATKOWE_3>X</DANE_DODATKOWE_3> <DANE_DODATKOWE_4>X</DANE_DODATKOWE_4> <POPRZEDNI_RACHUNEK>NRB poprzedniego rachunku sumy depozytowej</poprzedni_rachunek> <SEKTOR_KOD>Kod sektora/podsektora sumy depozytowej</ SEKTOR_KOD> <SEKTOR_OPIS>Opis sektora/podsektora</ SEKTOR_OPIS> </SUMA_DEP> Tabela kodów Sektor/Podsektor (tag <,SEKTOR_KOD>) oraz opisów (tag <SEKTOR_OPIS>) zdefiniowana u Zamawiającego przedstawia się następująco: OPIS KOD GRUPA I 01 GRUPA II 02 GRUPA III 03 GRUPA IV 04 NBP 05 Banki w Polsce (poza NBP) 06 Pozostałe krajowe instytucje finansowe 07 Przedsiębiorstwa niefinansowe 08 Gospodarstwa domowe 09 Instytucje niekomercyjne działające na rzecz gospodarstw domowych 10 str. 4
OPIS KOD Nierezydenci - strefa EURO 11 Pozostali Nierezydenci 12 Podmioty niezidentyfikowane 00 SD3_5. Dodanie opcji generowania w ZSD3 raportu na żądanie. Struktura pliku (raportu na żądanie z ZSD3) wczytywanego do bankowości elektronicznej jest następująca: [nazwa pliku, np. dane_sum_depozytowych.txt] ColNameHeader=False Format=Delimited(;) MaxScanRows=25 CharacterSet=OEM Col1=RACHUNEK_WIRTUALNY Char Width 34 Col2=SEKTOR_KOD Char Width 30 gdzie: RACHUNEK_WIRTUALNY - NRB rachunku wirtualnego (mikrorachunku) przenoszonego na nowy rachunek główny MF (pole wymagalne) SEKTOR_KOD - sektor/podsektor - kod pozycji słownika zdefiniowanego w wymaganiu SD3_4 (pole wymagalne), który powstaje w oparciu o słownik Kwalifikator RBN zdefiniowany w PCSD. Uwaga!! Dane do raportu będą pobierane z danych Kwalifikatora RBN wypełnionego przy partnerze handlowym w PSCD. W sytuacji gdy przy partnerze handlowym pole Kwalifikatora RBN nie jest wypełnione daną słownikową oraz dla pozycji zapisanych na księdze do wyjaśnień (brak przypisanego partnera handlowego, a tym samym brak powiązania z polem Kwalifikator RBN) do pliku wynikowego do bankowości elektronicznej powinien być wpisywany kod o wartości 00 (w nomenklaturze Banku: Podmioty niezidentyfikowane). str. 5