Kodėl individualių integracijų kūrimas energijos kilmės sertifikatų (EAC) registrams yra spąstai

Korporacijų inžinerijos komandoms paprastai tenka vertinti rinkoje veikiantį Energijos kilmės sertifikatų (EAC) registrų tinklą ir jos greitai supranta, kad reikia priimti sprendimą.

• A) Ar bandome šias integracijas kurti patys?
• B) Ar leidžiame komandai toliau gaišti valandas šokinėjant tarp platformų?
• C) Ar ieškome jau esamos integracijos?

Visiškai atvirai: esame čia kaip programinės įrangos teikėjas, kad atkalbėtume jus nuo A ir B. Turėsite mumis patikėti, kai sakome, kad taip yra ne vien todėl, jog turime komercinį interesą, bet todėl, kad aiškesnis matomumas tarp rinkų iš esmės yra sudėtinga užduotis, kurią Soldera sprendė metų metus - buvome įkurti 2024 m. ir nuo tada dirbame su savo Registry Bridge infrastruktūra.

Kai daugelyje registrų, su kuriais norite integruotis, apskritai nėra API, iš tikrųjų reikia individualaus jungiamojo audinio - specialių sprendimų vykdymui kiekvienoje rinkoje. Jūsų inžinerijos talentai niekada nesusidurs su ta pačia užduotimi du kartus: jie skirstys pastangas tarp konkrečioms šalims skirtų portalų, bandydami suderinti skirtingus prisijungimo būdus, sąskaitų taisykles, pervedimo protokolus, nevienodus panaikinimo įrodymų rinkinius ir atskleidimo terminus , kurie skiriasi tarp rinkų.

Kodėl EAC registrų integracijos tokios sudėtingos? Ar kai kurie turi įprastas API?

Galėtumėte manyti, kad visi jie turėtų API, bet ne. Registrus kūrė skirtingos programinės įrangos komandos kaip kontroliuojamas administracines sistemas valdžios institucijoms, o ne kaip kūrėjams patogius produktus (ar, tiesą sakant, naudotojams patogius produktus). Paimkime, pavyzdžiui, Europos GO sistemą: tarpusavyje sujungtų su AIB susietų EECS GO registrų tinklas savo esme sukasi aplink sąveikią atsiskaitymų sistemą - "AIB Hub" - tačiau paviršiuje patys registrai nėra vienodi.

Pavyzdžiui, jei būtumėte kompetentinga nacionalinės vyriausybės institucija (likite su mumis) ir norėtumėte pradėti savo registrą, tikriausiai žiūrėtumėte, kas kūrė esamus registrus, kad užtikrintumėte, jog jūsų produktas atitiktų AIB-Hub standartą. Susidurtumėte su 9 skirtingų paslaugų teikėjų sąrašu (rašymo metu), apimančiu daugiau kaip 30 registrų; kiekvienas jų sukūrė platformą, skirtą kontroliuojamai ir tarpusavyje sujungtai pervedimų patirčiai, tačiau kiekvienas paslaugų teikėjas neatsižvelgė į tai, kad naudotojai naudojasi keliais registrais. Jie nori prisijungti prie registrų skirtingose rinkose, kad valdytų visą savo portfelį. Vis dėlto API teikia tik kai kurie. Toliau pateikiama neišsami, aukšto lygio problemos masto pagrindinėse rinkose apžvalga

• Vokietijos HNKR registras neturi viešos API: https://www.hknr.de/Uba
• Ispanijos CNMC registras neturi viešos API: https://gdo.cnmc.es/
• Nyderlandų CertiQ neturi viešos API: https://verticer.eu/en/
• Trys Belgijos registrai neturi viešų API
• Lenkijos TGE RGP registras neturi viešos API: https://rgp.tge.pl/
• Švedijos CESAR registras turi labai riboto funkcionalumo API: https://cesar.energimyndigheten.se/sv/
• Suomijos Finextra platforma turi funkcionaliai ribotą API: https://go.finextra.fi/app/login

Ir tai tik keli Europos registrai (neįskaitant nesuskaičiuojamų "nišinių" rinkų visame žemyne) , aptarnaujantys kilmės garantijų rinkos dalyvius. Taip pat verta prisiminti: JK OFGEM RER sistema, skirta REGO valdymui, ir Evident I-REC sistema abi turi savitas taisykles, prisijungimus ir išdėstymus, įtrauktus į jų įvairius operacinius procesus, kuriems reikia skirtingų dokumentų formatų.

Bendra istorijos pamoka tokia: jei jūsų komanda daro prielaidą (kaip kadaise, prieš kelerius metus, darėme mes), kad po kiekviena rinka laukia viena stabili REST sąsaja, tikrai nemalonus darbas ateina vėliau. Žodį "nemalonus" čia vartojame pirmiausia todėl, kad tai daugiamatė problema: sunkumai kyla ne tik techninės integracijos požiūriu, bet ir siekiant užtikrinti, kad integracija atitiktų vietinės rinkos žinias reikalaujančią atitikties formą. Kūrėjams rinkos išmanymas turi labai mažai bendro su pagrindiniais techniniais gebėjimais.

Kur individualios integracijos paprastai sukelia problemų:

• Nuolatinės priežiūros sąnaudos: Portalų išdėstymai pernelyg dažnai keičiasi be jokio įspėjimo ar versijuotų pastabų kūrėjams.
• Laiką eikvojančios integracijos kliūtys: Rankinis autentifikavimas ir 2FA ypatumai sukelia rimtai nenuoseklius blokus, kuriems reikia kūrybiškų ir brangių apėjimo sprendimų, pavyzdžiui, sistemų su nuolatiniu veikimu ir eksploatavimo sąnaudomis
• Mokymasis veikiant: Tik apdorojant sandorius dideliu mastu galima išlyginti kai kuriuos tikrus registrų ypatumus. Patikėkite, susidūrėme su žiaurių, neracionalių klaidų realybe registro lygiu, kurios pasirodo tik tada, kai įrodymų reikia skubiai. Kartais šias klaidas patys turėjome pažymėti registro operatoriui, ir jos buvo ištaisytos.
• Pasekmės žemiau procese: Pasekmės atsiranda, kai jūsų auditui parengtuose įrodymuose yra spragų - o šios spragos atsiranda, kai padarote klaidą integracijos procese.

Ką korporacijų komandos turėtų kurti pačios?

Matome, kad mūsų klientai vieną dalyką daro geriau už viską: savo pagrindinį verslą. Tad kam gaišti laiką, kurį būtų galima skirti tvarumo strategijai? Kūrimo kontekste būkite pragmatiški. Kurkite vidines, į įmonę orientuotas sistemas ant EAC jungčių, kurios iš tikrųjų jau veikia , užuot deginę metų metus produktų kūrimo pajėgumų prižiūrėdami privatų registrų sąsajų muziejų. Laimei, jau veikiančios EAC jungtys egzistuoja.

Koks sprendimas?

Soldera Registry Bridge yra už jus parengtas atsiskaitymų sluoksnis ir API EAC, veikiantis kaip sklandi viso proceso atitiktis. Jis sukurtas būtent šiai problemai spręsti: esame įdiegę esamas sąskaitas kiekvienoje rinkoje, kad suteiktume vientisą talpinamos sąskaitos ir API paviršių pirkimui, gavimui, laikymui, siuntimui, pardavimui, panaikinimui ir įrodymų eksportui per daugiau kaip 30 registrų, įskaitant net sudėtingiausias rinkas be viešų API. Naudokite Registry Bridge tiesiogiai iš Soldera Web App arba, jei jūsų esamai įmonės programinės įrangos sąrankai reikia programinių ar integruotų registro veiksmų, jūsų komanda gali naudoti Soldera API kaip iš anksto sukurtą jungtį apačioje. Ji įgalina visas registrų elgsenas, įskaitant automatiškai nukreipiamus panaikinimus per vietinius registrus, kai tai prieinama.

Tai taip pat yra kritiškai svarbu misijai: vietiniai, registrais pagrįsti panaikinimo sertifikatai yra aiškiai geriausia praktika patikimiems RE100 atsinaujinančios elektros energijos teiginiams, ir tai dažnai nepastebima - nepaisant to, kad vietiniai panaikinimai beveik neabejotinai sulauks daugiau audito dėmesio, kai geografinis atitikimas taps aktualesnis tvarumo komandoms (žr. mūsų straipsnį apie GHG-P griežtinimo taisykles pereinant prie geografinio atitikimo). Taigi, užuot patys iš naujo kūrę registrų labirintą, pasitikėkite tais, kurie jau nuėjo tą varginantį kelią prieš jus, kad jums to daryti nereikėtų.