Kāpēc pielāgotu integrāciju veidošana enerģijas izcelsmes sertifikātu (EAC) reģistriem ir slazds

Korporatīvās inženieru komandas parasti nonāk pie tirgū esošā enerģijas izcelsmes sertifikātu (EAC) reģistru tīkla izvērtēšanas un ātri saprot, ka jāpieņem lēmums.

• A) Vai mēģinām šīs integrācijas veidot paši?
• B) Vai ļaujam komandai turpināt tērēt stundas, pārlecot starp platformām?
• C) Vai meklējam jau esošu integrāciju?

Pilnīgi godīgi: mēs šeit esam kā programmatūras nodrošinātājs, lai jūs atrunātu no A un B varianta. Jums būs mums jātic, kad sakām, ka tas nav tikai tāpēc, ka mums ir biznesa interese to darīt, bet tāpēc, ka skaidrāka pārskatāmība starp tirgiem pēc būtības ir sarežģīts uzdevums, kura atrisināšanai Soldera bija vajadzīgi gadi - mēs dibināti 2024. gadā un kopš tā laika strādājam pie mūsu Registry Bridge infrastruktūras.

Kad daudziem reģistriem, ar kuriem vēlaties integrēties, API nav vispār, tas patiesībā ir pielāgots savienojošais slānis - individuāli risinājumi izpildei katrā tirgū. Jūsu inženiertehniskie speciālisti nekad nesaskarsies ar vienu un to pašu uzdevumu divreiz: viņu darbs tiks izkliedēts pa konkrētām valstīm piesaistītiem portāliem, mēģinot saskaņot dažādus pieteikšanās ceļus, kontu noteikumus, pārvedumu protokolus, atšķirīgas dzēšanas pierādījumu pakas un informācijas atklāšanas termiņus dažādos tirgos.

Kāpēc EAC reģistru integrācijas ir tik sarežģītas? Vai dažiem ir normāli API?

Varētu pieņemt, ka tiem visiem ir API, bet tā nav. Reģistrus dažādas programmatūras komandas veidoja kā kontrolētas administratīvas sistēmas valsts iestādēm, nevis kā izstrādātājiem draudzīgus produktus (vai lietotājiem draudzīgus produktus, ja jau par to runājam). Piemēram, Eiropas GO sistēma: tīkls ar AIB savienotajiem EECS GO reģistriem savā būtībā balstās uz sadarbspējīgu norēķinu sistēmu, "AIB Hub" - taču ārējā slānī paši reģistri nav vienādi.

Piemēram, ja jūs būtu kompetentā iestāde valsts pārvaldē (palieciet ar mums šajā piemērā) un vēlētos izveidot savu paša reģistru, jūs, visticamāk, skatītos, kas ir izveidojis esošos reģistrus, lai nodrošinātu, ka jūsu produkts varētu atbilst AIB-Hub standartam. Jūs sastaptos ar 9 dažādu pakalpojumu sniedzēju sarakstu (raksta tapšanas brīdī), kas aptver 30+ reģistrus, un katrs no tiem ir izveidojis platformu, kas paredzēta kontrolētai un savstarpēji savienotai pārvedumu pieredzei starp reģistriem, taču katrs pakalpojumu sniedzējs nav ņēmis vērā faktu, ka lietotāji piekļūst vairākiem reģistriem. Viņi vēlas pieteikties reģistros dažādos tirgos, lai pārvaldītu visu savu portfeli. Tomēr tikai daži nodrošina API. Šeit ir neizsmeļošs, augsta līmeņa pārskats par problēmas mērogu lielākajos tirgos

• Vācijas HNKR reģistram nav publiska API: https://www.hknr.de/Uba
• Spānijas CNMC reģistram nav publiska API: https://gdo.cnmc.es/
• Nīderlandes CertiQ nav publiska API: https://verticer.eu/en/
• Trīs no Beļģijas reģistriem nav publisku API
• Polijas TGE RGP reģistram nav publiska API: https://rgp.tge.pl/
• Zviedrijas CESAR reģistram ir funkcionāli ļoti ierobežots API: https://cesar.energimyndigheten.se/sv/
• Somijas Finextra platformai ir funkcionāli ierobežots API: https://go.finextra.fi/app/login

Un tie ir tikai daži Eiropas reģistri (neskaitot neskaitāmos "nišas" tirgus visā kontinentā) , kas apkalpo izcelsmes apliecinājumu tirgus dalībniekus. Vērts atcerēties arī to: Apvienotās Karalistes OFGEM RER sistēmai REGO pārvaldībai un Evident I-REC sistēmai abām ir unikāli noteikumi, pieteikšanās veidi un izkārtojumi, kas iestrādāti to dažādajos operacionālajos procesos un prasa atšķirīgus dokumentu formātus.

Kopējā mācība ir tāda: ja jūsu komanda pieņem (kā mēs paši reiz pirms gadiem), ka zem katra tirgus gaida viena stabila REST saskarne, patiesi nepatīkamais darbs pienāk vēlāk. Mēs šeit lietojam "nepatīkams" galvenokārt tāpēc, ka tā ir daudzdimensionāla problēma: grūtības rodas ne tikai no tehniskās integrācijas skatpunkta, bet arī no pārliecības, ka jūsu integrācija atbilst vietējā tirgus zināšanām atbilstošā un regulām atbilstošā formātā. Izstrādātājiem tirgus zināšanām ir ļoti maz sakara ar pamattehniskajām spējām.

Kur pielāgotas integrācijas parasti rada problēmas:

• Pastāvīgas uzturēšanas izmaksas: Portālu izkārtojumi pārāk bieži mainās bez jebkāda brīdinājuma vai versētu izstrādātāju piezīmēm.
• Laiku tērējoši integrācijas šķēršļi: Manuāla autentifikācija un 2FA īpatnības rada ļoti nevienmērīgus bloķējumus, kam nepieciešami radoši un dārgi apejas risinājumi, piemēram, sistēmas ar pastāvīgu darbspēju un ekspluatācijas izmaksām
• Mācīšanās darot: Tikai apstrādājot transakcijas lielā mērogā, var izgludināt dažas patiesas reģistru īpatnības. Ticiet mums, mēs esam saskārušies ar skarbu, neracionālu kļūdu realitāti reģistra līmenī, kas parādās tikai tad, kad steidzami vajadzīgi pierādījumi. Reizēm mums pašiem nācies par šīm kļūdām ziņot reģistra operatoram, un tās tika salabotas.
• Pakārtotās sekas: Sekas, kas rodas, kad jūsu auditam gatavajos pierādījumos ir nepilnības - un šīs nepilnības parādās, kad integrācijas procesā pieļaujat kļūdu.

Ko korporatīvajām komandām vajadzētu veidot pašām?

Mēs novērojam, ka mūsu klienti vienu lietu dara labāk par visu citu: savu pamatbiznesu. Tātad kāpēc tērēt laiku, ko varētu veltīt ilgtspējas stratēģijai? Būvējot risinājumus, esiet pragmatiski. Veidojiet iekšējās, uzņēmumam pielāgotās sistēmas virs EAC savienotājiem, kas patiešām jau strādā , nevis izdedziniet gadu produktu kapacitāti, uzturot privātu reģistru saskarņu muzeju. Par laimi, EAC savienotāji, kas jau strādā, pastāv.

Kāds ir risinājums?

Soldera Registry Bridge ir gatavs risinājums, norēķinu slānis un API EAC vajadzībām, kas darbojas kā bezberzes pilna cikla atbilstības nodrošināšana. Tas pastāv, lai atrisinātu tieši šo: mēs esam izvietojuši esošus kontus katrā tirgū, lai nodrošinātu nevainojamu hostētu kontu un API virsmu pirkšanai, saņemšanai, turēšanai, sūtīšanai, pārdošanai, dzēšanai un pierādījumu eksportēšanai 30+ reģistros, tostarp pat sarežģītākajos tirgos bez publiskiem API. Izmantojiet Registry Bridge tieši no Soldera Web App, vai, ja jūsu esošajai uzņēmuma programmatūras videi nepieciešamas programmatiski/integrēti izpildāmas reģistra darbības, jūsu komanda var izmantot Soldera API kā iepriekš izveidotu savienotāju apakšslānī. Tas nodrošina visas reģistra darbības, tostarp automātiski maršrutētu dzēšanu caur vietējiem reģistriem, kur tas ir pieejams.

Tas ir arī kritiski svarīgi: vietējie, reģistra balstīti dzēšanas sertifikāti ir skaidra labākā prakse uzticamiem RE100 atjaunīgās elektroenerģijas apgalvojumiem, un tas bieži tiek palaists garām - neraugoties uz to, ka vietējās dzēšanas gandrīz noteikti saskarsies ar lielāku audita pārbaudi, jo ģeogrāfiskā piesaiste kļūst arvien nozīmīgāka ilgtspējas komandām (skatiet mūsu rakstu par noteikumiem saistībā ar GHG-P pastiprināšanu virzībā uz ģeogrāfisko piesaisti). Tāpēc tā vietā, lai paši no jauna būvētu reģistru labirintu, uzticieties tiem, kas jau ir izgājuši šo grūto ceļu pirms jums, lai jums tas nebūtu jādara.