Možnost računalniškega izmenjavanja podatkov

Možnost računalniškega izmenjavanja podatkov dinarskega plačilnega prometa med SDK, poslovno banko in podjetjem

POVZETEK

Prispevek obravnava elektronsko izmenjavanje dokumentov kot možnost nove storitve pri opravljanju notranjega plačilnega prometa. Prvi del daje pregled stanja v inozemstvu (ZDA in Kanadi kot državah, kjer se EDI najširše uporablja) z namenom povečevanja interesa za ta način poslovanja pri nas. V nadaljevanju je povzeto, kaj je na tem področju razvito in razpoložljivo pri nas. Končno je podana konceptualna rešitev za storitev, ki bi jo organizacija za plačilni promet lahko razvila in ponudila podjetjem in poslovnim bankam in ki bazira na že izdelanih prototipnih rešitvah.

KLJUČNE BESEDE: EDI, RIP, plačilni promet, banka, podjetje

SUMMARY

This article deals with electronic data interchange as a new service in domestic fund transfer. The first part tries to show foreign experience (mainly in U.S.A. and Canada) with intention to encourage our companies to implement this technique more widely. Next is shown what has been developed in this field and what is already available in our country. Finally, there is proposed a conceptual solution of a new service based on prototype software package and which could be offered to companies and banks by a clearing bank.

KEYWORDS: EDI, RIP, fund transfer, bank, company

V S E B I N A

1. Kaj vidijo v edifact drugi
2. Možnost rip v naših pogojih
3. Kaj smo uspeli napraviti doslej
4. Konceptualna rešitev
5. Sklepno razmišljanje

KAJ VIDIJO V EDIFACT DRUGI

Ideja o možnosti neposrednega komuniciranja računalnikov je stara kakor računalniki sami, rojena pa je bila verjetneje v svetu znanstvene fantastike kakor v poslovnem svetu. Danes je realnost. Celo več kot le to. Poslovno življenje postaja od tega bistveno odvisno, seveda tam, kjer se ta tehnika uporablja.

V ameriškem prostoru postaja računalniško izmenjavanje dokumentov (Electronic Data Interchange, EDI) standardni način poslovanja ("standard way of doing business" (5.10.)). Pri tem se misli na več kot le posredovanje podatkov med računalniki. Dejansko gre za to, da računalniki dokumente generirajo in si jih medsebojno izmenjujejo brez intervencije človeka. Analitik družbe Sears Roebuck & Co. ocenjuje, da je 70 % izhodnih podatkov enega računalnika vhod za neki drugi računalnik. Ekonomska upravičenost rešitev, ki omogočajo računalniško generiranje in izmenjavanje dokumentov, je očitna, koristi takih rešitev pa so še dodatne. V ZDA razvita rešitev EDIFACT (Electronic Data Interchange For Administration, Commerce, and Transport) je danes že mednarodni standard. Kot osnovni motivi za uporabo EDI v ameriškem prostoru so identificirani

1. upravičenost stroškov (cost effectiveness)
2. vzajemna dobrobit
3. dostopnost kateremu koli podjetju
4. neodvisnost od naprav
5. enostavnost uvedbe
6. možnost širitve uporabe

V državah, kjer se EDI uvaja, znaša prirast števila
podjetij, ki ga uporabljajo, okoli 100 % letno. V
državah, kjer je EDI praksa, je naraščanje števila uporabnikov počasnejše, vendar še vedno po več deset odstotkov letno (diagram 1). Gonilo za tak trend je industrija, uvajanje pa močno podpirajo vlade. Jasno mora biti, da je uvajanje EDI v podjetje stvar vodenja, ne pa tehnično področje. Angažirano mora biti vodstvo podjetja.

Motiv za EDI je torej učinkovitejše poslovanje. Na splošno rečeno se to lepo sliši, vendar mora biti uspešnost poslovanja kvantificirana, da bi lahko postala stvar vodstva podjetja. S pomočjo nekaterih konkretnih podatkov je koristi mogoče ovrednotiti. Poštna znamka v Kanadi stane na primer 32 centov, prenos sporočila preko elektronske pošte pa 39 centov.

Diagram 1: Naraščanje uporabe EDI v ZDA (vir: Computerworld, 5.3.1990).




V splošnem vidijo podjetja v uporabi EDIFACT naslednje koristi:

1. zanesljivost komuniciranja
2. maksimalno natančnost
3. dolgoročno manjše zaloge
4. manj pisarniškega dela
5. večjo učinkovitost prodajnih služb.

Maksimalno natančnost ilustrirajmo le z enim podatkom: podjetje Proctor & Gamble je ugotovilo 86 % večjo točnost podatkov, kar seveda pomeni ustrezno zmanjšanje stroškov odpravljanja napak in reševanja reklamacij. Še več: dobavitelji polizdelkov postajajo od EDI življenjsko odvisni in to je razlog, zakaj je uvajanje EDI stvar vodenja in strategije. V ZDA na primer da družba Ford dobavitelju osem mesecev časa, da preide na poslovanje z EDI, kolikor seveda želi biti še dalje njen poslovni partner. Po tem roku ga obvesti, da je "desourced", če medtem ni pričel poslovati na ta način. Tega izraza tudi v modernih slovarjih angleškega jezika še ne najdemo, je pa nov evfemizem za prekinitev poslovnih odnosov.

V poročilu EDI Research, Inc. O stanju EDI v ZDA: 1989 (The state of U.S. EDI: 1989) so objavljeni odgovori 423 uporabnikov, ki bodisi EDI že uporabljajo ali ga nameravajo uvesti, na vprašanje, kateri so glavni razlogi za uporabo. Anketiranci so lahko odgovorili po svoje. Odgovori so bili grupirani kar najbliže temu, kakor so se izrazili anketiranci. Najbolj pogost odgovor je bil hitrost in skrajšanje dobavnega roka in to kar v 49,9 % primerov. Drugi in tretji najbolj pogost odgovor, ki sta se pojavljala hkrati, sta bila stroškovna upravičenost in zahteva poslovnih partnerjev pri 15,1 % vprašanih. Povečana točnost je bila z 12,5 % naslednji najbolj priljubljen razlog, na petem mestu pa kvaliteta uslug (pri 3,6 % intervjuvancev). Zanimivo je, da nekatere opazne kvalitete EDI pri anketirancih ne kotirajo prav visoko. Zmanjšanje zalog je kot argument opazilo le 3,6 % anketirancev, čeprav ga tisti, ki EDI propagirajo, navajajo kot pomembnejšo korist od uporabe.

Poslovanje z EDI obsega v glavnem naslednje dokumente:

1. naročilnico
2. dobavnico
3. tovorni list
4. prevzemnico.

Zanimivo je, da med naštetimi dokumenti ne zasledimo računa in bi zato morebiti pričakovali, da bo račun izstavljen po klasični poti, to je s posredovanjem ljudi. Naročeno blago je seveda plačano, račun pa se preprosto ne izstavi. Presenetljivo je, da plačilo sledi kar obvestilu o prevzemu blaga in to brez izstavitve računa.

Glede na to, da EDI predstavlja v veliki meri poslovanje z računalniško generiranimi dokumenti, se postavita dve pomembni vprašanji in sicer vprašanje zaščite podatkov in vprašanje pravne veljavnosti takih dokumentov. Zaščita podatkov seveda mora biti razvita in vključena in tudi je. Zanesljivost sistema zaščite je več kot le zadovoljiva, tako da je družba General Electric ponudila pol milijona dolarjev nagrade entuziastu, ki bi sistem prebil, vendar nagrada še ni bila izplačana. To sicer ne pomeni, da je zaščita absolutna, kaže pa, da je tveganje res zanemarljivo v primerjavi s prednostmi.

Zanimivi so pravni vidiki takega načina poslovanja. Pozitivnih predpisov, ki bi tak način poslovanja dovoljevali ali kako drugače urejali, v Kanadi in ZDA ni. Vendar pa v preteklih dveh letih ni znan niti en primer spora pred sodiščem zaradi uporabe EDIFACT. Tudi v tem primeru ne smemo sklepati, da do spora v bodoče ne bi moglo priti, dokazuje pa, da je poslovanje znotraj uzanc gladko in brez večjega tveganja.

Shema 1: Potek prehoda na uporabo EDIFACT







Zapisali smo, da uporabo EDI podpirajo vlade. Ustanavljajo se sveti za računalniško izmenjavanje podatkov (EDI Council), ki izdajajo svoj bilten in prirejajo srečanja uporabnikov EDI. Bilten EDI council of Canada ima trenutno naklado 50.000 izvodov in trend naraščanja naklade. Prirejajo se seminarji za uporabo EDI, za katere je interes večji kot so možnosti realizacije seminarjev, tako da obstaja za udeležbo na seminarju lista čakanja. Državni zavodi za standardizacijo EDIFACT upoštevajo in ga priznavajo kot standard.

Programja za uporabo EDI danes nihče več ne razvija. Tako programje se (v ZDA in Kanadi) kupi in stane od 900 do 18.000 dolarjev, odvisno od okolja in naprav. Prehod na EDI poteka v fazah, ki so prikazane na shemi 1.

Končno še nekaj besed o stroških uvajanja. Čeprav je implementacija EDIFACT ali drugega (na primer X.400) standarda rutinska naloga, njene realizacije zaradi pomena za podjetje le ne bi smeli podcenjevati. Spomnimo se na podatek, da družba Ford počaka osem mesecev, preden se odpove sodelovanju s podjetjem, ki ne uporablja EDI. Računati je treba torej z določenimi stroški, ki so deloma vidni v obliki nabave naprav in programja, deloma pa skriti v obliki črpanja izvirov podjetja zaradi spremembe organizacije poslovanja. Očitno pa prednosti in koristi daleč prevladujejo pri odločitvi za EDI.

MOŽNOST RIP V NAŠIH POGOJIH

Pričujoči prispevek ne obravnava vseh možnosti računalniškega izmenjavanja podatkov v okviru standarda EDIFACT, temveč se omejuje na uporabo računalniškega izmenjavanja podatkov v notranjem plačilnem prometu. To sledi deloma iz strokovnih izkušenj avtorja, vsaj toliko pa tudi iz dejstva, da do danes standardnega obrazca za plačilni promet - splošnega prenosnega naloga - ni bilo mogoče preurediti po zahtevah EDIFACT. Trenutno torej kaže, da moramo, kolikor se bomo odločili za tak način poslovanja, razviti lastne rešitve kljub temu, da so za druga področja poslovanja standardne rešitve na razpolago. Kakor je to sicer neprijetno, ker pomeni predvsem kasnejšo možnost uporabe, pa je vendar tudi vzpodbudno, saj dokazuje, da dosedanji napori pri razvijanju aplikacijskega programja niso bili nepotrebni. Treba pa je le upoštevati, da so sveti in odbori EDIFACT aktivni, da podjetja širijo uporabo EDI na področje finančnega poslovanja in da bodo programi za konverzijo dokumentov plačilnega prometa prejkone kmalu na razpolago. Torej bi bilo dotlej priporočljivo lastno rešitev razviti do preprosto uporabne oblike, ki bi jo bilo mogoče ponuditi zainteresiranim podjetjem.

Storitev, ki jo je v naših pogojih in v okviru zgornje omejitve mogoče ponuditi, je opravljanje plačilnega prometa s tehniko in tehnologijo, ki sta vsaj blizu tistim v razvitih državah. Pri tem se misli predvsem na naslednje:

1. zajem plačilnega naloga v podjetju
2. pošiljanje  plačilnega  naloga  v organizacijo za plačilni    promet
3. vključitev plačilnega naloga v obdelavo nalogov
4. obvestilo podjetju, da je nalog sprejet
5. obvestilo upniku, da je plačilo izvršeno
6. vpogled v stanje računov iz podjetja
7. vpogled v stanje računov podjetij iz bank, katerih  komitenta sta podjetji

V nadaljevanju je podan opis dosedanjih rešitev za tak način poslovanja. Glede na že prikazane prototipske rešitve je razširitev v tem, da je že razvita možnost prenosa virmanskega naloga iz računalnika podjetja na osebni računalnik-terminal v podjetju, prenos vsakega naloga posebej v računalniško mrežo organizacije za plačilni promet ter obveščanje udeležencev finančne transakcije in njunih bank.

KAJ SMO USPELI NAPRAVITI DOSLEJ

V sodelovanju s Fakulteto za organizacijske vede v Kranju je bilo na osnovi že razpoložljivih aplikacijskih programov razvito programje, ki omogoča prevzem in kontrolo virmanskega naloga, vključitev naloga v plačilni promet, obdelavo naloga, sporočilo dolžniku in upniku o izvršitvi naloga ter omogoča vpogled v stanje računa obema subjektoma kakor tudi bankama, katerih komitenta sta dolžnik in upnik.

Razvita prototipna rešitev omogoča pravzaprav vse, kar bi bodoča tovrstna storitev morala nuditi po opisu v prejšnjem poglavju. Zaradi celovitosti prispevka jo bomo v nadaljevanju

 Slika 1: Shema on-line informacijskega servisa za plačilni promet






opisali nekoliko bolj obširno, saj bo s tem laže razumljivo, kaj bo predlagana storitev omogočala v končni obliki. Povemo naj še, da sta pri razvijanju rešitve ponudili sodelovanje dve podjetji, dve banki in podjetje, ki razširja programje za prehod na delo z EDIFACT. Glede na to, da je bil rezultat razvoja prototip, ki je sicer omogočal vse, kar je bilo načrtovano, da pa za preizkusno uporabo v podjetju ali banki ni bil mišljen, je bil ves razvoj opravljen na enem mestu. Iz razlogov, ki smo jih že navedli, pa standarda EDIFACT za plačilni nalog ni bilo mogoče uporabiti. Povemo naj še, da je bil opisani prototip javno prikazan in da je interes potencialnih uporabnikov take storitve resnično ogromen.

Potek obdelave transakcije, ki smo jo imenovali on-line informacijski servis, je prikazan na sliki 1. POD1 IN POD2 sta podjetji, BANKA1 in BANKA2 sta poslovni banki, katerih komitenta sta podjetji, SDK1 in SDK2 sta podružnici SDK, pri katerih imajo zgornji subjekti odprte račune, IK1 in IK2 interni kontroli v podružnicah, SDK pa predstavlja računalniško mrežo SDK.

Prototipna rešitev je bila razvita za povezavo z računalniškimi sistemi IBM (VM, DOS/VSE), uporaba rešitve, to pomeni delo na tak način, pa je mogoča le v okviru možnosti, ki jih dopuščajo sedanja navodila in ostali zadevni predpisi. Rešitve so bile načrtovane tako, da za izpeljavo ni bila potrebna dodatna računalniška oprema. Programi so se izvajali na računalniškem sistemu IBM 4341 v Ljubljani. Osebni računalnik IBM PS/2, ki lahko deluje kot ekranski terminal, je služil za prikaz zajema podatkov v podjetju, ekranski terminal pa je bil namenjen za vpogled v stanje računa. Prototipa nista bila prikazana v naravnem okolju, to se pravi v podjetju in v banki, ker je to praktično neizvedljivo na eni lokaciji. Ekranski terminal je simuliral ekranski terminal SDK v interni kontroli in ekranski terminal v banki, preko katerega je mogoč vpogled v stanje računov komitentov, osebni računalnik pa je bil računalnik za zajem podatkov plačilnega naloga v podjetju in je obenem služil kot naprava za prenos podatkov v SDK. V tej fazi tudi ni bilo treba angažirati resursov podjetij, ki sta ponudili sodelovanje.

Osebni računalnik in ekranski terminal sta bila instalirana na lokaciji, kjer je potekal prikaz, preko oddaljene kontrolne enote IBM 3274 C61 pa sta bila povezana z računskim centrom na drugi lokaciji. Zaradi varnosti tekočih obdelav so bile na računalniškem sistemu formirane posebne testne datoteke plačilnega prometa.

KONCEPTUALNA REŠITEV

Obstajajo nekatere objektivne omejitve, ki preprečujejo ponudbo storitve že v tej fazi in ki smo jih širše obravnavali v drugih prispevkih, med katerimi je gotovo najmočnejša področje predpisov, ki naj tako tehniko dovolijo. Naslednja, katere vplivov doslej nismo podrobneje proučevali, je število podjetij, ki bi želela opravljati plačilni promet na tak način. Storitev ne more biti namenjena samo nekaterim uporabnikom ne glede na to, po kakšnem kriteriju bi jih izbrali. To naprej pomeni, da je treba računati na veliko število uporabnikov. Po oceni bi se za uporabo take storitve odločilo vsaj tisoč podjetij v Sloveniji. Za organizacijo za plačilni promet predstavlja tako število on-line uporabnikov ne glede na zmogljivost sedanjih računalniških naprav prav s tege vidika obremenitev, ki ji ta trenutek ni kos, so pa problemi te vrste rešljivi v roku enega leta. Po znani modifikaciji fizikalnega principa nedoločljivosti, da rešitev problema spremeni naravo problema, se zdaj situacija obrne: organizacija za plačilni promet bo sicer zmogla sprejeti in obdelati podatke vseh interesentov, vendar ti podatkov ne bodo mogli poslati na obdelavo in ne bodo dobili prostih kanalov za vpogled v stanja svojih računov. Nobena organizacija namreč nima komunikacijskega sistema, ki bi bil dovolj zmogljiv, da bi lahko v kratkem času vključil poljubno veliko število oddaljenih aktivnih delovnih postaj in terminalov, katerih število bi bilo vsaj za faktor dva večje od števila podjetij. Tak problem ni rešljiv niti v enem letu niti zgolj s povečevanjem števila komunikacijskih kanalov.

Druga kategorija problemov, ki preprečuje uporabo take storitve, je heterogenost računalniških naprav in programja pri uporabnikih. V prejšnjem poglavju je bilo opisano, za kakšno okolje so rešitve razvite. Ni mogoče pričakovati, da bo pri takem številu uporabnikov organizacija za plačilni promet mogla upoštevati specifiko vsakega posebej. Za rešitev problemov, ki jih povzročijo zgoraj opisani kategoriji omejitev, je treba torej najti nov pristop.

Rešitev je v tem, da se okrog sistema za obdelavo podatkov zgradi zmogljiv komunikacijski sistem, ki bo

1. dovolj  zmogljiv  za  prenos  podatkov  velikega  števila podjetij
2. dovolj neobčutljiv za hitro povečanje števila uporabnikov
3. neodvisen od naprav in programja uporabnikov.

Tak komunikacijski sistem vidimo v novi poštni storitvi - elektronskem poštnem predalu (JUMAIL). Z uporabo te storitve odpravimo problem zmogljivosti komunikacijskega podsistema organizacije za plačilni promet, obenem pa tudi problem heterogenosti računalniških naprav pri potencialnih uporabnikih. Shema poteka finančne transakcije je razvidna iz slike 2, kjer predstavljajo P1 inP2 podjetji - dolžnika in

Slika 2: On-line servis za plačilni promet z uporabo elektronskega poštnega predala












upnika, B1 in B2 banki, katerih komitenta sta podjetji, SDK organizacijo, ki opravlja plačilni promet, PPP1, PPP2, PPB1, PPB2 in PPSDK pa elektronske poštne predale zgornjih subjektov.

Po predlaganem konceptu bi potekalo plačilo takole: podjetje - upnik pošlje virmanski nalog preko svojega poštnega predala v poštni predal organizacije za plačilni promet, ki svoj poštni predal prazni glede na poprej izbrane kriterije (število nalogov, čas). Prevzeti nalog se vključi v obdelavo podatkov plačilnega prometa, kjer je prva faza obdelave kontrola. Če je nalog pravilen, se obdela, obvesti se upnika, da je plačilo izvršeno, dolžnika, da je nalog obdelan, in obremenijo ali odobrijo se računi upnika, dolžnika in njunih bank. Analogno temu bi potekala tudi obdelava zahteve za vpogled v stanje računa. V praksi bi bilo treba razviti dva tipa transakcij in sicer :

• za obdelavo virmanskega naloga in
• za vpogled v stanje računa.

Transakcija za obdelavo virmanskega naloga bi potekala po naslednjih fazah:

1.1. pošiljanje naloga v poštni predal organizacije za plačilni promet (PPSDK)

1.2. prevzem naloga, ki vključuje

-    oznako, da je nalog v obdelavi
-    zaklepanje naloga

1.3. obdelava, ki vključuje naslednje postopke:

-    kontrola avtorizacije pristopa
-    vključitev naloga v plačilni promet
-    kontrola naloga
-    kontrola kritja na računu
-    zbiranje podatkov za evidence iz plačilnega prometa
-    protokol (logging)

1.4. posredovanje informacij

-    dolžniku o obremenitvi računa in plačilu (v PPP1)
-    upniku o odobritvi računa in plačilu (v PPP2)
-    - odobritev in obremenitev računov bank obeh komitentov

1.5. pospravljanje poštnega predala organizacije za plačilni promet

Faze transakcije za vpogled v stanje računa bi bile naslednje:

2.1. zahteva za vpogled v stanje računa (v poštni predal)

2.2. prevzem zahteve, ki obsega

-    označbo zahteve, da je v obdelavi

2.3. obdelavo zahteve, ki vključuje

-    kontrolo avtorizacije subjekta, ki zahteva podatek
-    izbor podatkov
-    protokol

2.4. vračanje podatkov v poštni predal subjekta, ki jih je zahteval

2.5. pospravljanje poštnega predala PPSDK

Prednost predlaganega koncepta vidimo v tem, da je zagotovljena možnost vključevanja velikega števila uporabnikov, ne da bi se zaradi tega obremenjeval komunikacijski podsistem organizacije za plačilni promet. Poleg tega mora taka poštna storitev omogočati zaščito ter tajnost podatkov in varnost pristopa, kar bi bilo treba sicer šele razviti, da bi bil sistem dovolj zanesljiv.

SKLEPNO RAZMIŠLJANJE

Zgornji koncept se omejuje na računalniško izmenjavanje podatkov plačilnega prometa. Doslej razvite programske prototipne rešitve omogočajo tudi vpogled v druge zbirke podatkov (statistična poročila, periodični in zaključni računi, investicije, register imetnikov računov, interaktivno delo preko sistema za upravljanje baz podatkov SQL), česar posebej tu ne opisujemo, deloma zato, ker smo o tem že poročali, deloma pa iz razloga, ker se omejujemo le na plačilni promet. Razume se, da so tudi te rešitve zanimive, vprašanje je le, v kakšni obliki so lahko v prihodnje na razpolago. Interesentov po naših izkušnjah ne manjka.

Morda je bilo opaziti, da se v prispevku v zvezi z bodočimi storitvami plačilnega prometa dokaj dosledno uporablja izraz organizacija za plačilni promet. Tržno gospodarstvo, ki je sicer po avtorjevem prepričanju naravno stanje ekonomije, bo prineslo spremembe tudi na tem področju. Iz tega razloga se interna kontrola kot postopek pri obdelavi finančne transakcije posebej ne omenja, po potrebi pa se lahko v nove rešitve vključi, ker je v obstoječih že razvita.

Kljub nekaterim nejasnostim, ki so prisotne prav v tem času, je razmišljanje o novih storitvah v plačilnem prometu na mestu. Tehnika jih omogoča, čas zanje pa je, kakor lahko vidimo iz pregleda, kaj se dogaja v svetu, tudi dozorel. Elektronsko bančništvo kot posplošitev elektronskega denarja postaja okoli nas že rutinski način poslovanja. Nejasnosti so predvsem v tem, kakšen bo bodoči plačilni sistem, katera organizacija bo opravljala plačilni promet in po kakšnih pravilih. Menimo, da bo moralo priti do konkurence tudi na tem področju, eden od pomembnih kriterijev za to, komu bodo podjetja zaupala opravljanje te storitve, pa bo gotovo tudi cena.

Predlagani koncept omogoča uporabo elektronskega denarja in tudi elektronsko bančništvo precej tako, kakor ga razume zahod. Storitev bi bilo mogoče ponuditi velikemu številu uporabnikov naenkrat, omejitve pa v tem primeru postavlja zmogljivost poštne infrastrukture. Varnost, ki je bila videti eden od ključnih zadržkov, je rešen problem v okviru poštne storitve. Zakonitost takega načina poslovanja, ki je bila identificirana kot glavna ovira za uvedbo informacijskih servisov, ki so že razviti bi jih bilo mogoče ponuditi, je morebiti pri nas še vedno vprašljiva. Vendar naj ponovno navedemo podatek, da pri uporabi EDIFACT v Kanadi, ki ni niti posebej dovoljena niti posebej prepovedana, v dveh letih ni bilo niti enega sodnega spora iz tega naslova - kjer je volja, tam je pot. Volja in želja pri uporabnikih sta.

Dejansko je položaj tak, da je mogoče ponuditi le delujoč prototip za tako storitev, kar bi zadovoljilo uporabnika, ki bi pristal na poizkusno delo, in omogočilo izpiliti obstoječo rešitev. Za kaj več v smislu realizacije predlaganega koncepta je treba razviti dopolnitve obstoječe rešitve, ki bodo omogočale sprejem plačilnih nalogov v en poštni predal in pošiljanje podatkov v predale mnogih uporabnikov. Trenutno ni razen razvijalcev prototipne rešitve nikogar, ki bi bil sposoben dopolniti že razpoložljivo programje s temi funkcijami, pač iz razloga, ker virmanskega naloga trenutno še ni mogoče uskladiti z EDIFACT. Treba pa je računati s tem, da je interes za to velik in je uskladitev po prepričanju avtorja le še vprašanje (ne prav dolgega) časa. Možnosti za realizacijo take storitve sta pravzaprav le dve. Ena je počakati, dokler ne bo na voljo z EDIFACT usklajen plačilni nalog. Druga, ki jo podpira avtor in ki bi bila uresničljiva v največ enem letu, pa je dopolnitev obstoječe rešitve po predlaganem konceptu.