Változásnapló
A Veridyn fejlődése hónapról hónapra — a termékútlevél-motor első verziójától a fejlesztői API-ig. A dátumok a funkció megjelenésének hónapját jelzik; a lényeges változásokat itt vezetjük.
A kapcsolati üzenetek is lejárnak
A kapcsolati űrlapon érkező megkeresés (név, e-mail, cég, üzenet) eddig határidő nélkül állt az admin postaládában, az Adatvédelmi tájékoztató pedig csak egy „pl. 1 év” jelölést mutatott a helyén. Mostantól a megkeresés 24 hónap után automatikusan törlődik, ugyanaz az ütemezett takarítás hajtja végre, mint a beolvasás-naplót — és a tájékoztatóban is ez a szám áll, nem egy helykitöltő. Az űrlap mellett ott a rövid tájékoztatás is: mire használjuk az üzenetet, milyen jogalapon, és meddig őrizzük.
Tanúsítvány-feltöltés és beszállítói adatbekérés gépből
Két olyan funkció volt eddig csak böngészőből elérhető, amit épp a gépi úton kell használni. A dokumentum-feltöltés: a tanúsítvány PDF-je egy dokumentumkezelőben vagy a laborral folytatott levelezésben keletkezik, nem egy böngésző-fülben — mostantól base64-ben feltölthető, letölthető és törölhető az API-ból. A típust a tartalom dönti el, nem a fájlnév: a PDF-nek hazudott fájlt elutasítjuk. A beszállítói adatbekérés: a szövöde vagy a cellagyártó adatát kérő link indítása, a beküldés átnézése és beolvasztása is gépből megy — így egy beszerzési rendszer nem csak az 500 útlevelet tudja feltölteni, hanem az 500 adatbekérést is elindítani.
Inkrementális szinkron: csak a változások
Egy ERP nem tudja minden éjszaka végigolvasni a teljes útlevél-állományt. Az <code>updated_since</code> paraméterrel mostantól csak a változott útlevelek jönnek vissza — minden szinten (modell, tétel, darab) —, kurzoros lapozással. Kurzorral, és nem oldalszámmal: a lapszámos lapozás némán kihagy sorokat, ha közben módosul egy már látott elem. Az archivált útlevél sem esik ki a listából: <code>archived</code> státusszal jön, ebből tudja a rendszered, hogy le kell vennie.
Életciklus, verziók és hatósági hozzáférés az API-ból
Amit eddig csak a felületen lehetett, most gépből is megy: archiválás és visszaállítás (új verzió gyártása nélkül — a láthatóság-váltás nem adat-változás), a változás-történet mező-szintű különbséggel, és a lejáró hozzáférési linkek kiadása hatóságnak vagy jogos érdekű félnek. Az utóbbin szándékosan nincs csomag-kapu: a hatósági hozzáférés jogszabályi elvárás, nem felár tárgya.
A PATCH megmondja, mit ejtett el
A <code>PATCH /products/{id}</code> felső szintű kulcsonként olvas rá az adatra. Ha tehát egy beágyazott objektumot (például <code>dimensions</code>) csak részben küldesz be, a nem küldött testvér-mezők elvesznek — és ahol az objektumnak nincs kötelező almezője, ott eddig a mentés sikeres volt, az adat pedig csendben eltűnt. A viselkedést szándékosan NEM változtattuk meg (a teljes csere lehet szándékos, és a mély összefésülésre váltás visszamenőleg törné a meglévő hívásokat), de a válasz mostantól kimondja: a <code>dropped_fields</code> felsorolja a kiesett mezőket, és <code>warning</code> is jön hozzá. A korábbi verzió érintetlen marad a változás-történetben, tehát visszaállítható.
Szabványos fogalmak a darab-útlevél gépi adatában
Egy darab-útlevél gépi kimenetéből eddig hiányzott a GTIN — a gépnek a szülő-útlevelet is le kellett kérnie, hogy megtudja, melyik termék egyedét látja. A típus <code>Product</code> volt, holott a schema.org <code>IndividualProduct</code> pontosan ezt jelenti: „egy termék egyetlen, azonosítható példánya". A sorszám és a módosítás ideje pedig csak a saját <code>dpp:</code> fogalmaink alatt szerepelt, a szabványos <code>serialNumber</code> és <code>dateModified</code> alatt nem. Mind a négy javítva, és additívan: a régi <code>dpp:</code> mezők a helyükön maradtak, a szabványosak melléjük kerültek — egyetlen mai integráció sem törik el.
Ismeretlen sorszám: megmondjuk, hogy nem találtuk
Ha valaki egy nem létező tétel- vagy sorszámot olvas be — elírás, sérült QR vagy hamisítvány —, eddig csendben a modell útlevelét kapta. Ez a legrosszabb válasz: úgy nézett ki, mint egy érvényes termékútlevél. Mostantól a rendszer a legközelebbi ismert szintet adja, és a lap tetején figyelmeztet, hogy a beolvasott azonosítót nem találtuk. Gépi kérésnél <code>404</code> jön <code>unknown_identifier</code> kóddal és a modell URL-jével, a lap pedig <code>noindex</code>-et kap, hogy hamis azonosító ne kerüljön a keresőkbe.
Te is látod, ha bementünk a fiókodba
A támogatáshoz néha be kell lépnünk egy fiókba. Ez eddig is módosíthatatlan naplóba került — csak épp a mi oldalunkon, ahol te nem láttad. Egy ellenőrizhetetlen ígéret pedig nem ígéret. Mostantól a Beállítások között a saját naplód is ott van: mikor léptünk be, mikor léptünk ki, meddig tartott. A munkatárs személyét szándékosan nem írjuk ki — az a mi belső felelősségünk —, de a tény és az időtartam a tiéd. Emellett minden olyan verzió, amit megszemélyesítés közben mentettünk, meg is van jelölve a változás-történetben, tehát utólag is látszik, hogy nem te írtad. Ehhez javítottuk azt is, hogy a kijelentkezés minden úton lezárja a bejegyzést — eddig egy lezáratlan sor örökre „bent van"-t mutatott.
Az import beszélő hibát ad a túl nagy fájlra
Egy nagy vagy sérült táblázat eddig a kiszolgáló memória-korlátján akadt el, és a böngésző csak egy eltört választ kapott — semmi nem mondta meg, mi a baj. Mostantól a feltöltés három ponton is ellenőrzött: a fájl mérete (legfeljebb 16 MB), a munkafüzet belső bejegyzés-száma, és a kibontott méret (legfeljebb 32 MB). Mindhárom esetben rendes, magyarázó hibaüzenetet kapsz, és megmondjuk a korlátot is. Nagy állomány esetén bontsd több részre — az import többször is futtatható.
A számok mértékegysége mostantól gépi adat
Egy szám önmagában nem adat: a <code>ratedCapacity: 2500</code> lehet 2500 Ah vagy 2500 mAh, és a kettő ezerszeres eltérés. A mértékegység eddig csak az emberi mezőcímkében volt ott — a séma-végpont nem közölte. Mostantól minden számmező <code>unit</code> mezőt is ad (<code>GET /api/v1/schema/{category}</code>), és a <a href="/ns/dpp/v1">szókészlet-lap</a> is kiírja. A legfontosabb eset a szénlábnyom: az akkumulátornál energiára normált (<code>kg CO₂e/kWh</code>), a textilnél darabra (<code>kg CO₂e</code>) — ugyanaz a mezőnév, összemérhetetlen számok. Ezt eddig semmi nem jelezte.
Séma-verzió: jelezzük, ha változik a szerződés
A kategóriák mezőlistája a jogszabállyal együtt mozog, és eddig semmi nem jelezte a változást — az integrációk némán romlottak el. A séma-végpont mostantól verziót és ETag-et ad: amíg <code>304</code>-et kapsz, nincs dolgod. Az ujjlenyomat a gépi szerződésből áll (mező, típus, kötelezőség, enum, hozzáférési szint), a címke- és súgó-átírás tehát nem ad vaklármát. Visszafelé nem kompatibilis váltásnál <code>Deprecation</code> és <code>Sunset</code> fejléc is jön.
Élő darab-adat visszaírása tömegesen
A darab-szintű mezők egy része élő adat: az akkumulátor egészségi állapota, ciklusszáma és maradék kapacitása a BMS-ből frissül. Ezt mostantól egy hívásból legfeljebb 500 darab-útlevélre lehet visszaírni, sorozat- vagy tételszám alapján — a mi belső azonosítónkat nem kell eltárolnod. Aminek az értéke nem változott, ott nem keletkezik üres verzió: egy napi flotta-szinkron nem szennyezi tele a változás-történetet.
GTIN-tulajdon védelme
A GTIN a gyártó GS1 cégprefixéből épül, és egy termékazonosító idegen fiókban félrevezető útlevelet eredményez. Mostantól megadhatod a saját GS1 cégprefixedet: a rendszer nem engedi, hogy azon kívül eső GTIN-t rögzíts. Prefix nélküli fiókoknál a tartomány-ellenőrzés marad (a bolti, kupon- és demó-tartományok kizárása), és minden vitatott azonosító bejelenthető — bejelentkezés nélkül.
Webhook: azonosított események, pótlás, újraküldés
Az újrapróbálkozás azt jelenti, hogy ugyanaz az esemény többször is megérkezhet. Ezért minden esemény kap egy saját azonosítót (az aláírt törzsben és fejlécben is), amivel a duplikátum kiszűrhető. Ha a rendszered tartósan elérhetetlen volt, az esemény korábban elveszett — most a teljes esemény-történet lekérdezhető, kézbesítési állapottal, és onnan folytathatod, ahol abbahagytad.
BatteryPass-megfelelőség: 11/11
A BatteryPass-Ready megfelelőségi vizsgálat mind a 11 tesztjén átmegyünk — háromszor egymás után megismételve, hogy ne a szerencse döntsön. A vizsgálat nem beküldött fájlt néz: hálózaton szólítja meg az élő rendszert, és azt méri, a szabvány szerint viselkedik-e — olvasás azonosító és termékazonosító szerint, mezőnkénti hozzáférés-szűrés, verziózott módosítás, attribútum hozzáadása és törlése, visszavont útlevél, jogosultság-ellenőrzés, és a piacra hozatal bejelentése.
Teljes JTC24-lefedettség
A hivatalos EV-adatmodell minden leképezhető mezőjét ki tudjuk adni. Megmértük, mert a séma-validátor erre nem válaszol: korábban 211-ből 129 ment, vagyis 61% — tizennégy mezőcsoport egyszerűen nem létezett nálunk (abszolút szénlábnyom, tanúsított és maradék hasznos energia, kadmium/ólom jelölés, jótállás, üzembe helyezés dátuma, túltöltési és mélykisütési események, ellátásilánc-kockázati mutatók, anyagonkénti újrahasznosított tartalom). A lefedettséget mostantól teszt őrzi, hogy ne eshessen vissza némán.
Szabvány szerinti gépi felület
A saját fejlesztői API-nk mellett mostantól a CEN-CENELEC JTC 24 életciklus-API (EN 18222) végpontjait is kiszolgáljuk — azon a nyelven, ahogy az akkumulátor-ökoszisztéma többi szereplője beszél. Szerepkör szerinti hozzáféréssel, és a piacra hozatalhoz tartozó kötelező kimenő hívásokkal: másolat a független mentés-szolgáltatóhoz, majd bejelentés a regiszterbe — ebben a sorrendben, mert a bejelentés a mentés azonosítóját kéri.
Jogszabályi teljesség mentés előtt
A „menthető" és a „jogilag teljes" két külön dolog: az első néhány mező, ami nélkül nincs értelmes rekord, a második az, ami fölött bírságolnak. A szerkesztő mostantól mentés előtt figyelmeztet, ha az útlevél jogilag hiányos — megmutatja a százalékot, a hiányzó mezőket és a jogforrást. Nem tilt, mert az adat gyakran szakaszosan gyűlik, de nem is engedi csendben kimenni. A megfelelőségi műszerfal külön oszlopban mutatja a műszaki érvényességet és a jogszabályi teljességet.
Idegen akku-útlevél beolvasása
Egy másik szolgáltatótól kapott JTC24-dokumentum mostantól beolvasható, szerkeszthető, és változatlan formában visszaadható. A mezőit a sajátjaink alá képezzük; amire nincs saját mezőnk, azt érintetlenül megőrizzük, és az exportban visszaadjuk. Ez a szolgáltatóváltás gyakorlati feltétele: nem elég kiexportálni az adatot, a másik oldalnak be is kell tudnia olvasni — és fordítva.
Szakaszonkénti mezőszámláló
Az akkumulátor-útlevélnek nagyon sok mezője van. Minden szakasz fejlécén mostantól látszik, hány mezőt tartalmaz, abból mennyi kell a mentéshez, és mennyi jogszabályi kötelező — így nem nyitogatva kell megkeresni, hol van még dolgod.
Töltsd le bármelyik verziót
Minden útlevél-verzióról változtathatatlan pillanatkép készül, hash-bélyeggel. A verziótörténetből bármelyik letölthető JSON-ban — az adatod kivitele mostantól egy kattintás, nem ígéret. A hatósági hozzáférési linkkel a piacfelügyelet is eléri.
Teljes lánc a felületről
Egyedi darab mostantól közvetlenül gyártási tétel alá is felvehető — a tétel azonosítóját örökli, így a rá nyomtatott QR a teljes modell → tétel → darab láncot mutatja. A tétel- és darab-útlevelek pedig archiválhatók és bármikor visszaállíthatók: törlés nincs, mert a kinyomtatott QR nem adhat 404-et.
Korlátlan tétel- és darab-útlevél
A csomagok mostantól csak a modell-útlevelek számát mérik: a gyártási tétel- és az egyedi darab-szintű útlevél minden fizetős csomagban korlátlan (fair use). Azt, hogy melyik szintre van szükséged, a rád vonatkozó rendelet dönti el — az akkumulátor-rendelet 2027. február 18-tól darab-szintet ír elő —, nem az árlistánk.
Elavult darab-útlevelek jelzése
A tétel- és darab-útlevelek a létrehozáskori modell-adat pillanatképét őrzik (ez adja a hash-lánc bizonyító erejét). Mostantól nyilvántartjuk, melyik modell-verzióból származnak: ha később hibát javítasz a modellen, a rendszer jelzi, hány kiadott útlevél avult el, és egy kattintással frissíthető mind. Ha viszont maga a termék változott (pl. új beszállító), a korábbi darabok adata érintetlen marad — az a maga korában helyes.
Nyílt béta program
Bárki csatlakozhat: minden funkció ingyen 100 modell-útlevélig, per-fiók időkorlát nélkül. A béta végén a korai fiókok tartós founder-kedvezményt kapnak.
Fejlesztői REST API + interaktív referencia
OpenAPI 3.1 spec, letölthető Postman-kollekció, hatókörös (teljes vagy csak-olvasható) kulcsok, percenkénti rate limit, idempotencia-kulcsok, valamint aláírt és automatikusan újrapróbált webhookok — böngészhető, kereshető API-referenciával.
Hamisítás-gyanú riasztás
Ha egy egyedi (sorszámozott) termék QR-kódját sok különböző országból olvassák be — ami egy fizikai darabnál szokatlan —, a rendszer klón-gyanúként jelzi (riasztás + webhook).
Adathordozhatóság és folytonosság
Bármikori export (JSON-LD / GS1 Digital Link) kiviteli zárolás nélkül, és folytonossági garancia — a QR-kódok akkor sem halnak meg, ha elköltöznél.
EU DPP-regiszter felkészültség
Vámtarifaszám (CN) mező, „regiszter-kész" jelölők, és lépésről lépésre eIDAS-hitelesítési útmutató a központi EU-regiszterhez.
Rétegzett hozzáférés + megosztható tokenek
Nyilvános / jogos érdekű / hatósági szint, megosztható, lejáró hozzáférési linkekkel — az érzékeny adat feletti kontroll nálad marad.
Beszállítói adatbekérés
Kérj be adatot és dokumentumot a beszállítóidtól belépés nélküli, lejáró linken, majd egy kattintással olvaszd be a termékbe.
Dokumentum-tár + hash-lánc
Csatolj megfelelőségi dokumentumokat (tanúsítványok, adatlapok) az útlevélhez, és minden verzióhoz kriptográfiai hash-lánc készül — bizonyíthatóan változatlan adat.
Beolvasás-analitika
Ország-, eszköz- és időbontású beolvasás-statisztika a műszerfalon, mérföldkő-webhookkal — lásd, hol és mikor nézik a termékeidet.
24 EU-nyelv az útlevélen
A publikus termékútlevél mind a 24 hivatalos EU-nyelven megjelenik, a látogató nyelvéhez igazodva — kulcs-alapú fordítási motor, nem gépi félrefordítás.
Tudástár + DPP-készültségi teszt
Adat-vezérelt útmutatók a DPP-szabályozásról (ESPR, határidők, szankciók), és egy ingyenes készültségi teszt, ami megmutatja, hol tartasz a megfelelésben.
Élő, kipróbálható demó
Regisztráció nélkül kipróbálható, mintaadatokkal feltöltött demó-fiók — hogy belépés előtt lásd, hogyan néz ki és működik a rendszer.
Számlázási rendszer (béta alatt inaktív)
Free / Starter / Pro / Business / Enterprise csomagok, próbaidőszak, Stripe Embedded Checkout, ÁFA-kezelés és csomagon felüli extra útlevél-keret — beépítve, de a béta alatt inaktív (mindenki ingyenes teljes hozzáférést kap).
Admin-konzol
Belső üzemeltetői konzol: működési mutatók, naplózott ügyfélszolgálati hozzáférés, üzenet-beérkező és fiók-kezelés egy helyen.
E-mail-értesítők + jelszó-visszaállítás
Üdvözlő és kapcsolatfelvételi levelek, valamint biztonságos jelszó-visszaállítás — saját SMTP-n, megbízható kézbesítéssel.
Verziózott útlevelek + változás-történet
Minden módosítás új verziót hoz létre, teljes változás-történettel és „frissítve" dátummal — az útlevél mindig auditálható.
Vezetett útlevél-szerkesztő
Készültség-gyűrű, szakaszokra bontott űrlap és „kezdd itt" jelölők — a kötelező EU-mezők kitöltése lépésről lépésre, kihagyott mező nélkül.
Többformátumú tömeges import
Termékek tömeges behozatala CSV, XLSX, JSON és XML fájlból, a mezők automatikus illesztésével — nagy katalógus percek alatt.
A termékútlevél-motor
Elindul a Veridyn: séma-vezérelt EU digitális termékútlevelek kód nélkül — kategória-sablonok (akkumulátor, textil, bútor…), QR-kód és útlevél-oldal minden termékhez.
GS1 Digital Link + JSON-LD + egységes téma
Szabvány-alapú publikus útlevél: GS1 Digital Link URL-ek, JSON-LD strukturált adat a keresőknek és gépeknek, valamint egy egységes, világos/sötét téma.