# CVN — céges belépéstől a követeléses rendezésig

2026. október 10. • UX- és use case specifikáció • 0.3

## Hol tartunk

Kész az architektúra, SQL-adatterv, domain/chain interfész, jogi döntési keret, ügyleti klauzulavázlat és helyi üzleti referencia. A 21 referenciateszt 2026. október 10-én is sikeres. A korábbi felület az átadás és rendezés példáját mutatta; az új bemutató az előkészítő ügyfélutat is lefedi. Nincs még CVN-backend, valódi cégellenőrzés, dokumentumtárolás, aláírás, NFT-kibocsátás vagy lánckapcsolat.

## Szereplők és kiindulás

- A / Alfa Kft.: követelést tart nyilván C-vel szemben, és B felé tartozik.
- C / Gamma Kft.: az eredeti kötelezett. Választott példánkban részt vesz a háromoldalú megállapodásban.
- B / Beta Kft.: A hitelezője; átveszi A követelésének egy részét, és meghatározott módon rendezésként elfogadja.
- CVN: fogadja és ellenőrzi a szükséges adatokat, támogatja a dokumentumfolyamatot és bizonyítékot rögzít. Nem azonos az ügylet gazdasági kötelezettjével.
- Reviewer / jogi és számviteli szakember: saját szerepe szerint dönt a dokumentált feltételekről; nem ír alá az ügyfél helyett.

A háromoldalú megállapodás itt választott termékfolyamat. A Ptk. az engedményezést az engedményező és az engedményes szerződéseként határozza meg; az eredeti kötelezett értesítése és a teljesítési utasítás külön kérdés. C közreműködését nem általános, minden engedményezésre előírt jogszabályi feltételként kezeljük. [Ptk., 6:193–198. §](https://net.jogtar.hu/jogszabaly?docid=a1300005.tv).

## Folyamatábra

```mermaid
flowchart TD
  Start["A cég regisztrál"] --> KYB["Cég és képviselet ellenőrzése"]
  KYB --> Member{"Aktív tag?"}
  Member -->|Nem| FixCompany["Hiánypótlás vagy elutasítás"]
  FixCompany --> KYB
  Member -->|Igen| Contract["Szerződés, partner, dokumentumok feltöltése"]
  Contract --> Classify["Követelés / kötelezettség / WIP elkülönítése"]
  Classify --> Claim{"Azonosított, bevonható követelés?"}
  Claim -->|Még nem| WIP["Teljesítés vagy jövőbeli követelés jelöltje"]
  WIP --> Review["Jogalap és bizonyíték szakmai vizsgálata"]
  Review --> Claim
  Claim -->|Igen| Reserve["A forrásrész és az A–B célkötelezettség foglalása"]
  Reserve --> Agreement["A–B–C digitális megállapodás"]
  Agreement --> Conditions["Elfogadás, képviselet, aláírás, értesítés és hatályfeltételek"]
  Conditions --> Ready{"A választott feltételek teljesültek?"}
  Ready -->|Nem| Hold["Függő ügylet vagy új dokumentumverzió"]
  Hold --> Agreement
  Ready -->|Igen| Assign["Követelésrész átadása és gyermekpozíció"]
  Assign --> Evidence["Bizonyítékrögzítés / opcionális NFT-hivatkozás"]
  Assign --> Mode{"Rendezés időpontja?"}
  Mode -->|Átadáskor| Reduce["A–B kötelezettség csökkentése"]
  Mode -->|Beszedéskor| Collect["C igazolt teljesítése"]
  Collect --> Reduce
  Reduce --> Export["Rendezési csomag és könyvelői review"]
  Evidence --> Export
```

A rajz nem teszi a láncrögzítést jogi hatályfeltétellé minden ügyletnél. A szerződés határozza meg a joghatás időpontját; a horgonyzás technikai állapota külön követhető. A bemutatóban az „átadás” gomb a választott ügyleti feltételek teljesülését szimulálja.

## Képernyők és kapuk

| Képernyő | Bemenet / művelet | Kimenet / továbblépés |
|---|---|---|
| Folyamat áttekintése | Szereplők, ügylet és lépések | Egy konkrét A–B–C példa indítása |
| Céges regisztráció | Cégnév, nyilvántartási azonosító, ország, képviselő, jogosultsági nyilatkozat | Tagsági és képviseleti ellenőrzés; csak az aktív cég adhat be ügyletet |
| Szerződés és dokumentum | Típus, partner, szerződéses érték, követelés összege, esedékesség, PDF / mintareferencia | Verziózott forrás; nem automatikus követelési vagy NFT-egyenleg |
| Követelés vizsgálata | Jogalap, teljesítés/folyósítás, vita, teher, korábbi átadás, átadhatósági review | Indokolt alkalmas összeg vagy további vizsgálat |
| Háromoldalú megállapodás | Forrásrész, célkötelezettség, elfogadási érték, rendezési mód, A/B/C szerepspecifikus nyilatkozata | Befagyasztott, azonos dokumentumcsomag; valós rendszerben ellenőrzött aláírások |
| Digitális pozíció | Átadott rész, eredet, új jogosult, dokumentumkapcsolat; opcionális NFT-referencia | A maradvány és B gyermekpozíciója, külön rögzítési státusszal |
| Rendezés és bizonyíték | Azonnali vagy beszedéskori csökkenés, maradványok, eseménylista | Export és külön könyvelési elfogadás |

## Konkrét szolgáltatási use case

1. A teljesített C-nek egy 10 000 USD értékű fejlesztést. A példában a teljesítés és a 10 000 USD követelés megfelelően dokumentált; nincs korábbi átadás/teher.
2. A B-nek 6 000 USD üzemeltetési díjjal tartozik. Ezt a célkötelezettséget külön forrásszerződés/okirat azonosítja.
3. A a C-vel szembeni követeléséből 6 000 USD-t ajánl fel B-nek. A forrás és a cél összege együtt foglalódik; a dokumentumok is verzióhoz kötöttek.
4. A átadást vállal; B elfogadja az adott követelést és a rendezési feltételt; C a választott háromoldalú folyamatban rögzíti a tartozásra, új jogosultra és utasításra vonatkozó nyilatkozatát. Vita vagy módosítás új review-t jelent.
5. Azonnali rendezési változatnál A–B nyitott tartozása 0; C A-nak 4 000, B-nek 6 000 USD-vel tartozik. C összes nyitott tartozása az átadás miatt nem csökken.
6. Beszedéskori változatnál A–B tartozása az átadástól még 6 000 USD. A megfelelően hozzárendelt beszedés vált ki csökkenést; a dupla teljesítés és visszkereset kezelése a megállapodás része.

## Más forrásügyletek

Eladott áru: szállítás/átadás, vételár, esedékesség és kifogások dokumentációja. Szolgáltatás: mérföldkő, elfogadás és díjfeltételek. Már folyósított kölcsön: kölcsönokirat, folyósítás, visszafizetési feltétel és külön tevékenységi besorolás. Saját fizetési kötelezettség: rendezési cél, nem saját követelési eszköz. Még nem teljesített együttműködés: WIP/jövőbeli jelölt; külön policy nélkül nincs átadható keret.

A rendszer nem indít vagy finanszíroz automatikusan kölcsönt. A kölcsön- és követelésvásárlási szerepek felügyeleti vizsgálata külön kapu. [MNB: engedményezési tájékoztatás](https://www.mnb.hu/letoltes/tmp55c4-tmp-11652734.pdf).

## NFT és digitális megállapodás

A digitális megállapodás a jognyilatkozatokat tartalmazó, aláírt dokumentumcsomag. Az okosszerződés a technikai állapotokat kezelheti. A pozíció/NFT az adott követelésrészhez hivatkozást adhat. Ez három külön réteg.

Az ERC-721 egyedi tokenazonosítót és opcionális metadata-URI-t biztosít. Tervezési javaslat: privát PositionRegistry az elsődleges rekord, későbbi, kontrollált NFT-hivatkozás a pozícióra. A követelés joga nem az ERC-721 szabványból származik. [ERC-721](https://eips.ethereum.org/EIPS/eip-721).

A PDF nem teljes egészében kerül az NFT-be vagy a láncra. Hozzáféréssel védett tárban marad; tartalmi hash, verzió és jogosultság kapcsolja a bizonyítékhoz. Nyilvános metadata-URL és közvetlen dokumentumhash nem használható automatikusan bizalmas céges adatokhoz. A UI-ban látható 6 000 USD a követelés névértéke/elfogadási értéke, nem az NFT garantált piaci ára.

Részátadáskor új gyermekpozíció keletkezik; egy NFT nem darabolható egyszerű tokenküldéssel pénzegységekre. A forrás maradványa, a gyermek és az okiratok együtt biztosítják a követhetőséget. Közvetlen wallet-transfer nem kerülheti meg a review/aláírás/rendezési feltételeket.

## A következő fejlesztési terv

1. A most bemutatott folyamat adatmezőinek és ügyleti sablonjainak véglegesítése, jogi/számviteli döntések rögzítése.
2. Egy teljes üzleti MVP: céges belépés és jogosultság → dokumentumtár/verzió → követelés-review → sorzáras forrás/cél foglalás → háromoldalú ügylet → bizonyítékexport. Valódi adatbázis és szerveroldali ellenőrzés.
3. Valós képviselet/aláírás/kézbesítés és végrehajtási helyreállítás. A külső szolgáltatások nem egyetlen DB-tranzakció részei.
4. Privát EVM/registry, outbox/indexer és egyeztetés. Opcionális NFT csak az üzleti és hozzáférési szabályokkal együtt.

Első elfogadási teszt: ugyanazt a 10 000 USD-s követelést két párhuzamos ügylet nem használhatja fel kétszer; eltérő dokumentumra tett aláírás nem érvényes a friss csomagra; C elutasítása a választott háromoldalú ágat megállítja; lánchiba nem vonja vissza némán a már hatályos ügyletet.