Testno okolje bomo postopno vzpostavili v času od 15.4. do 15.5.2010. Banke bodo pred vzpostavitvijo obveščene o uporabniških imenih in geslih za dostop. 

Za identifikacijo bodo ponudniki plačilnih storitev potrebovali kvalificirano digitalno potrdilo enega od overiteljev, ki so registrirani v Sloveniji.

Osnutki kontrolnih shem (XSD) so že objavljeni, WSDL-ji spletnih servisov z vključenimi osnovnimi kontrolami bodo predvidoma objavljeni v kratkem.

V XML strukturah se bo uporabljal kodni nabor UTF-8, ki je bil naveden v posredovanih vzorcih, izdelanih z orodji za upravljanje z XML strukturami.

Glede na predloge in pripombe bank bomo za izmenjavo podatkov prek spletnih servisov namesto WS-Security uporabljali klasično izmenjavo po zaščitenem kanalu – SSL / https: in identifikacijo strežnikov s kvalificiranimi digitalnimi potrdili. Posebnega e-podpisovanja SOAP sporočil ne bo.

Za oddajo podatkov po SFTP bo zadoščala prijava z uporabniškim imenom in geslom. Podatki bodo med prenosom zaščiteni - šifrirani. Posebnega e-podpisovanja datotek ne bo.

Ponudniki plačilnih storitev bodo lahko uporabljali kvalificirana digitalna potrdila (KDP) enega od registriranih overiteljev digitalnih potrdil v Republiki Sloveniji.

Nekvalificiranih digitalnih potrdil ne bo mogoče uporabljati. KDP se bodo uporabljala samo za identifikacijo strežnika/ov ponudnika in AJPES.

Trenutna specifikacija je povzeta iz obstoječega sistema, kjer sta BBAN in prefiks »SI56« v ločenih poljih. Niza se na izpisih vedno lahko izpišeta skupaj. Razlogi za drugačno ureditev nam niso poznani, če obstajajo jih lahko preučimo.

Sistem mora biti za vse ponudnike plačilnih sistemov enoten, zato bodo morali vsi ponudniki uporabljati izmenjavo prek spletnih servisov. Do 1.7.2010 morajo banke izdelati sistem izmenjave podatkov prek spletnih servisov vsaj v "paketni" obliki (za več računov hkrati), prek katerega bodo lahko periodično posredovali podatke na AJPES in od tam tudi prevzemali spremembe. Ciljna integracija s sprotnim pošiljanjem posameznih sprememb se lahko izvede tudi kasneje.

Izmenjava podatkov na XML datoteki naj bi se izvedla samo za prvo - inicialno polnjenje registra in v primeru nedelovanja osnovnega sistema.

• Za register transakcijskih računov (RTR): začetno polnjenje registra bo poskrbel AJPES na podlagi podatkov, ki jih bo posredovala Banka Slovenije.
• Za neporavane obveznosti (NODURS): ponudniki plačilnih storitev bodo 30. 6. 2010 poslali XML datoteko s celotno bazo podatkov (z vsemi odprtimi in zaprtimi dogodki) za vse dospele neporavnane obveznosti od 1. 1. 2010 do vključno 30. 6. 2010.
• Za promet in stanja na TRR (SPAPP): ponudniki plačilnih storitev bodo 30. 6. 2010 poslali XML datoteke od 1. 1. 2010, in sicer za mesece januar, februar, marec, april, maj in junij (za vsak mesec posebej) za vse transakcijske račune, ki so predmet poročanja, vključno s podatki za samostojne podjetnike.

Po grobi oceni AJPES bi bilo to okrog 1 minute.

Šifrante bo AJPES objavil na svojem spletnem portalu. O njihovi spremembi bodo udeleženci vnaprej obveščeni. Ker se šifranti predvidoma ne bodo pogosto spreminjali, trenutno možnost prevzemanja prek spletnih servisov ni predvidena.

Izvleček DURS za posredovanje ponudnikom plačilnih storitev ni več predviden, ker bodo banke lahko podatek o davčni številki pravnih oseb dobile prek wsPrsInfo iz Poslovnega registra Slovenije (PRS). V PRS se podatek o matični in davčni številki že usklajuje in sproti ažurira.

AJPES bo naslove iz Slovenije programsko preverjal v Registru prostorskih enot, ki ga vodi Geodetska uprava RS, in jih ustrezno šifriral, da bo mogoče dnevno usklajevanje naslovov s tem registrom in tako programsko posodabljanje naslovov v primeru preimenovanja ulic in naselij ipd.

Za pravne osebe ponudnikom plačilnih storitev poslovnega naslova ne bo potrebno posredovati, za fizične osebe pa ga bodo morali posredovati zgolj v tekstualni obliki. AJPES bo naslov v tekstualni obliki primerjal z naslovi fizične osebe.

AJPES bo usklajeval podatke z matičnimi registri: 

• s Poslovnim registrom Slovenije (PRS) prek matične številke poslovnega subjekta,
• s Centralnim registrom prebivalstva (CRP) prek davčne številke,
• z Registrom prostorskih enot (RPE).

Če se bodo podatki o naslovu ujemali s podatki o naslovu po RPE iz CRP, bodo podatki o transakcijskem računu vpisani v RTR, sicer pa bo vrnjena ustrezna napaka in podatki o naslovu v primarnem registru, na osnovi katerih bo banka lahko naredila ustrezne popravke.

AJPES bo ponudnikom plačilnih storitev vračal podatke o poslovnem naslovu pravnih oseb in stalno ter morebitno začasno bivališče fizičnih oseb. Za imetnike transakcijskih računov z naslovom v Sloveniji bodo naslovi vrnjeni v šifrirani in tekstualni obliki, za tuje imetnike transakcijskih računov pa samo v tekstualni obliki.

V primeru sprememb podatkov o imetnikih transakcijskih računov v matičnih registrih se bodo ti podatki enkrat dnevno osveževali tudi v RTR, na podoben način (z dodajanjem novega zapisa s spremenjenimi podatki), kot če bi jih spremenili ponudniki plačilnih storitev sami. Tako spremenjeni zapisi bodo označeni kot spremenjeni. Uporabniki jih bodo lahko prevzeli prek spletnih servisov ali enkrat dnevno v XML datoteki sprememb RTR.

AJPES bi želela poenotiti izmenjavo vseh vrst podatkov s ponudniki plačilnih storitev na spletne servise. Pri poročanju SPAPP je bilo ocenjeno, da glede na obstoječ obseg podatkov, velikost XML datoteke lahko dosegla nekaj 10 MB tudi, če se vsebina stisne. Po izkušnjah AJPES lahko taka velikost niza prenesenih podatkov znotraj enega SOAP sporočila v določenih primerih povzroča težave oziroma se pri prenosih pojavljajo napake. AJPES je zato podobne prenose do nekaj 100 MB reševal s prenosom reference (URL-ja) datoteke na strežniku pošiljatelja prek WS in prenosom same XML datoteke prek http:/https:. Druga možnost je, da se velike datoteke prenašajo po ustrezno majhnih kosih v ločenih SOAP sporočilih, kar pa je morda za implementacijo nekoliko bolj zahtevno. Glede na to, da naj bi se prenosi SPAPP izvajali enkrat mesečno, nismo želeli dodatno obremenjevati ponudnikov plačilnih storitev, zato smo predlagali samo SFTP prenos, ki mora biti v vsakem primeru realiziran zaradi izmenjave v izrednih razmerah.

Vsak dogodek se obravnava neodvisno. Če poročevalci ugotovijo, da je bil eden od dogodkov nepravilen oziroma neustrezen, ta dogodek OBVEZNO stornirajo z novim (dodatnim) zapisom »00«, ki se nanaša na zaporedno številko dogodka (No/Id). Sistem AJPES v bazi vodi revizijsko sled, zato bo stornirani dogodek (z originalnim datumom zapisa v bazo) v bazi ostal, dodatno se bo v bazo zapisal storno dogodek z novim datumom zapisa v bazo. Pri pripravi podatkov o neporavnanih obveznostih se stornirani zapisi in zapisi, s katerim se je storno izvedel, ne bodo upoštevali. Kot do sedaj bo neporavnana obveznost (blokada) odprta z zapisom »01«. V bazi AJPES bo veljala za odprto, dokler ne bo eksplicitno zaprta z eno od oznak, ki eksplicitno zapirajo blokado, torej ne glede na stanje delnih poplačil, ki jih vodi banka. AJPES iz dogodkov na blokadi namreč ne izvaja nobenih kalkulacij na osnovi zneskov blokad in delnih poplačil, programsko torej blokad ne »zapira«. STORNO zapis je potreben samo v primeru popravkov oziroma evidentiranja sprememb, drugače to polje ni obvezno.

Identifikacijska številka blokade (Blok/id) enolično določa dospelo neporavnano obveznost (blokado) na nivoju banke. Ta identifikator mora biti enoznačen ne glede na stanje blokade (odprte, že zaprte, …), saj služi za povezovanje vseh dogodkov na posamezni blokadi.

Identifikacijska številka dogodka (No/id) je zaporedna številka v okviru dospele neporavnane obveznosti (blokade) in enolično določa dogodek znotraj posamezne blokade. Identifikator se uporablja tudi kot referenca na pri stornu posameznega dogodka na blokadi. Primer: stornacija dogodka delnega poplačila – dogodek #2 blokade.