Kas yra virtualus IBAN?
Virtualus IBAN (vIBAN) yra tikras, adresuojamas tarptautinis banko sąskaitos numeris, išduodamas iš tam skirto diapazono ir nukreipiamas į vieną pagrindinę sąskaitą. Jis priima mokėjimus kaip ir bet kuris kitas IBAN — mokėtojas iš savo banko siunčia įprastą SEPA kredito pervedimą — tačiau pats neturi jokio likučio. Jo paskirtis — identifikavimas: kadangi kiekvienas virtualus IBAN priskirtas tik vienam mokėtojui ar paskirčiai, jame gautas mokėjimas jau parodo, kas jį išsiuntė ir už ką. Pinigai į pagrindinę sąskaitą susikaupia automatiškai; virtualus IBAN yra mokėjimo etiketė, o ne antra vieta, kur pinigai laikomi.
Ši viena savybė — vienas IBAN vienam mokėtojui — ir yra visa idėja. Kad suprastume, kodėl apie tai verta rašyti straipsnį, pradėkime nuo problemos, kurią ji pašalina.
Tikroji problema: pinigų priskyrimas mokėtojams
Įsivaizduokite įmonę, kuri į vieną sąskaitą renka banko pervedimus: nuomą, prenumeratas, sąskaitas faktūras. Visos įplaukos patenka į tą patį IBAN, o vienintelė užuomina, kas sumokėjo, — tai, ką mokėtojas įrašė į mokėjimo paskirties laukelį. Paskirtys būna įvestos su klaidomis, kažkur grandinėje sutrumpinamos arba visai palieka tuščios. 49,00 € pervedimas su sugadinta paskirtimi dar nėra 49,00 € pripažintų pajamų — tai užduotis. Kažkas turi išsiaiškinti, kuriam klientui ir kuriai sąskaitai jis priklauso, kol dar neuždarytos knygos.
Esant mažam kiekiui tai tik nepatogumas. Platformos apimtimis tai jau visas skyrius. Suderinimo sistemos vertina galimas sąskaitas pagal sumą, datą ir neapibrėžtą paskirties tekstą; ko nepavyksta priskirti, patenka į žmonių eilę. O problema struktūrinė: kai du prenumeratoriai tą pačią dieną sumoka tą pačią sumą be paskirties, jokia sistema jų neatskirs — informacijos, kuri juos išskirtų, mokėjime iš pradžių niekada nebuvo.
Vienas IBAN vienam mokėtojui: tapatybė pagal konstrukciją
Virtualių IBAN programa apverčia požiūrį. Užuot prašę kiekvieno mokėtojo teisingai pažymėti mokėjimą, kiekvienam suteikiate jo paties adresą. Kiekvienas nuomininkas, prenumeratorius ar prekyvietės pardavėjas moka į tik jam priklausantį IBAN. Paskirties laukelis gali būti klaidingas, tuščias ar užpildytas kita abėcėle — įplaukos vis tiek save identifikuoja, nes tapatybę perduoda sąskaitos numeris.
Sąskaitos numeris yra daug geresnis tapatybės nešėjas nei mokėjimo paskirtis. IBAN turi savo kontrolinius skaitmenis, todėl su klaida įvestas IBAN neišlaiko patikros mokėtojo banke dar prieš išsiunčiant pervedimą. Su klaida įvesta paskirtis praeina sklandžiai ir tampa jūsų problema. Perkėlus tapatybę iš laisvo teksto laukelio į adresą, klaidų patikra iš jūsų administravimo skyriaus pereina siunčiančiam bankui.
Mokėtojui niekas nesikeičia: jis moka IBAN iš savo bankininkystės programėlės, kaip ir visada. Visa naujovė — gavėjo pusėje: mokėjimas atkeliauja jau pažymėtas, o paskirties laukelis vėl tampa tuo, kuo ir turėjo būti — pastaba, o ne identifikavimo sistema.
Kai kiekvienas mokėtojas moka į savo IBAN, gautas mokėjimas gali reikšti tik vieną dalyką. Suderinimo problema neišsprendžiama — ji tiesiog nebeegzistuoja.
Kur iš tikrųjų yra pinigai
Po apačia kiekvienai valiutai yra tik viena pagrindinė sąskaita. Virtualūs IBAN išduodami iš programai skirtų diapazonų, o kiekvienas į bet kurį iš jų pervestas kreditas patenka į pagrindinę sąskaitą. Nereikia valdyti mokėtojų likučių, nėra dienos pabaigos užduočių, kurios lėšas iš tūkstančių mažų sąskaitų perkeltų į vieną — sukaupimas vyksta maršrutizavimu, o ne papildomais pervedimais, kuriuos vėliau reikėtų derinti atskirai.
Todėl virtualus IBAN yra tikras, o ne triukas. Jį galima adresuoti iš bet kurio banko, jis apdorojamas kaip bet kuris SEPA kreditas ir mokėtojo išraše rodomas kaip sąskaita, į kurią jis sumokėjo. Jam trūksta būtent to, ką tempia visavertė sąskaita: savo likučio ir gyvavimo ciklo, išskyrus priskyrimą ir nutraukimą.
Kuo virtualus IBAN nėra
Tai nėra subsąskaita: subsąskaita turi likutį, ją reikia papildyti ir ištuštinti, o jūsų tvarkomų knygų daugėja. Tai nėra virtualus nuorodos numeris: jie vis tiek keliauja paskirties laukelyje ir vis tiek priklauso nuo to, ar mokėtojai teisingai nukopijuoja eilutes. Ir tai nėra piniginė: pačiame vIBAN niekas nesaugoma. Tai adresas su maršrutizavimu už jo — siauriausia konstrukcija, dėl kurios gaunamas mokėjimas save identifikuoja.
Grąžinimai ateina su priežastimi
Mokėjimai ne tik ateina. Sąskaitos uždaromos, bankai atmeta kreditus, mokėtojai atšaukia pervedimus. Su viena surinkimo sąskaita grąžinimas yra mažas tyrimas: kuris mokėjimas grįžo, kieno jis buvo ir ar reikia atšaukti buhalterinį įrašą, kuriam jis buvo priskirtas?
vIBAN programoje grąžinimas yra duomenys. Jis turi priežasties kodą, atsiranda kaip įvykis payment.returned prie to paties virtualaus IBAN, kurį naudojo pradinis kreditas, ir išraše turi savo skaičių. Žinote, kieno mokėjimas grįžo ir kodėl, dar prieš kam nors atidarant užduotį. Grąžinimai tampa eilutėmis, kurias reikia apdoroti, o ne paslaptimis, kurias reikia gaudyti.
Išimčių eilė, o ne suderinimo komanda
Joks sprendimas nesuderina šimto procentų ko nors. Kreditai ateina į jau nutrauktus vIBAN. Pasitaiko dublikatų. Kažkas, kažkaip, sumoka tiesiai į pagrindinę sąskaitą. Tikslas — ne padaryti išimtis neįmanomas, o padaryti jas retas ir suskaičiuojamas. Protocore vIBAN demonstracijoje 99,6 % kreditų suderinama automatiškai; likusieji patenka į peržiūros eilę su visa mokėtojo istorija, todėl išimties nagrinėjimas prasideda nuo konteksto, o ne nuo banko išrašo ir skaičiuoklės.
Šis skirtumas keičia komandą. Suderinimo operacija auga kartu su mokėjimų apimtimi: daugiau kreditų, daugiau nesuderintų kreditų, daugiau žmonių. Išimčių procesas auga kartu su išimčių skaičiumi, kurį konstrukcija jau nuspaudė link nulio. Likę žmonės nagrinėja tikras anomalijas, o ne iš naujo suvedinėja paskirtis. Mūsų sistemoje ta eilė yra Protocore Center (/products/center) — operacijų konsolėje, kurioje kiekvienam privilegijuotam veiksmui reikia nurodyti priežastį, o pats veiksmas patenka į audito žurnalą.
Masinis išdavimas, paskirties žymos, platformos
Vienas IBAN vienam mokėtojui veikia tik jei jo išdavimas nieko nekainuoja. Nuomotojas su tuzinu nuomininkų gali sukurti vIBAN rankiniu būdu; prekyvietė, prisijungianti tūkstančius pardavėjų, — ne. Todėl išdavimas yra masinė operacija. vIBAN demonstracijoje 2 400 mokėtojų CSV failas patikrinamas, kiekvienoje eilutėje parodomas IBAN peržiūrai, ir visi išduodami vienu veiksmu — 2 400 mokėtojų, viena operacija, o tarp jų — peržiūros žingsnis.
Paskirties žymos išskiria srautus adreso lygiu: nuoma čia, prenumeratos ten, prekyvietės išmokos — savo juostoje. Ataskaitos pagal paskirtį tampa filtru, o ne projektu, o kiekvienas vIBAN gauna savo išrašą — CSV arba PDF, — kai tuo tarpu pagrindinė sąskaita apačioje lieka vienintele tiesos linija. Kai mokėtojas išeina, jo vIBAN nutraukiamas: istorija lieka, adresas nebepriima naujų kreditų.
Kur tai telpa mokėjimų sistemoje
Virtualūs IBAN yra surinkimo infrastruktūra. Jie gaunamiems banko pervedimams suteikia tai, ką kortelių mokėjimai turėjo visada — tapatybę, pridėtą prie paties mokėjimo, o ne įvedamą šalia. Protocore ekosistemoje Gateway mokėjimo pervedimu užsakymai turi vIBAN nuorodas, o Center sprendžia visas išimtis, kurias palieka suderinimas. Produkto puslapis /products/viban pereina visą ciklą — išduoti, pasidalyti, suderinti, išimtys, ataskaitos — su tais pačiais demonstraciniais duomenimis, kurie naudojami čia.
Ir sąžininga riba: jei per mėnesį gaunate saujelę pervedimų, užtenka paskirties susitarimo ir dešimties minučių apskaitos. Virtualūs IBAN atsiperka ten, kur dėl apimčių suderinimas tapo procesu — nuomos sąrašai, prenumeratų surinkimas, prekyvietės — visur, kur klausimas, kas jums sumokėjo, užduodamas tūkstančius kartų per mėnesį.
Turite sistemą, kurią reikia sukurti?
Papasakokite apie problemą. Grįšime su architektūra ir planu.