06 — Integrációk

Származtatott dokumentum — a docs/discovery/ anyagból. Frissítsd a requirement-handling skill-lel, ne kézzel a forrásokból.

Források: 02-tender-v1.0.hu, 00-annex-b-architecture-v1.0.hu, 05-beforg-feed-fields, 07-butlers-tender-answers-hu, 08-loyalty-api-trimmed, 09-loyalty-clarification

Külső rendszerek

Rendszer	Irány	Adat / cél	Megjegyzés
Beforg (termékadat-hub)	Beforg → Platform	Beszállításonként egy fájl: beszállítás-fejléc (szállítmány-hivatkozás, várható beérkezés, raktár, deviza, árfolyam) + cikkenként teljes cikkrekord a beszállítási tétellel (mennyiség, nettó egységköltség HUF-ban); cikkrekord: cikkszám, EAN, HU/DE nevek, DE leírás, webes variánscsoport, kategória, attribútumok, méretek/súly/csomagolási egységek, származás, vámtarifaszám, HU fogyasztói ár, áfa, nettó beszerzési ár, státusz, képek	JSON; a platform kizárólag innen kap termékadatot. Nem része: készlet, akciós árak, HU/CZ/SK leírások. Az átadás a szállítólevél beárazásakor, a fizikai beérkezés előtt 2–3 nappal történik; a mennyiség tájékoztató, törlés nincs. Átvitel (pull/push) és gyakoriság a szerződéskötéskor rögzítendő; a Beforg-oldali fejlesztést a Társaság végzi.
Butlers Germany (heti feed)	Germany → Beforg	Heti árufeed (termék-vázak / item shells)	A Beforg dolgozza fel; a platform a német feedet semmilyen formában nem dolgozza fel (a válaszlevél G-02 pontja ezt a szabályt minden ajánlattevőre egyformán érvényesen rögzíti, és felváltja a „B" melléklet B.2 2. pontjában említett kétforrású modellt).
NAV Online Számla	Platform → NAV	Számlák adatszolgáltatása	Kötelező integráció; szamlazz.hu vagy Billingo közvetítésével, vagy közvetlen NAV Online Számla 3.0 kapcsolattal (a válaszlevél szerint mindkettő elfogadható, lásd 02-requirements → WP-24). A platform állítja ki a számlákat.
szamlazz.hu / Billingo	Platform ↔ Szolgáltató	Számla-kiállítás és NAV-jelentés	A konkrét szolgáltató az ajánlattevő javaslatától függ; a szamlazz.hu megtartása nem kötelező, de a teljes bizonylat-életciklust, a teljes archívum-hozzáférést/exportot és a NAV-sémaváltozások követését le kell fednie.
Fulfillment-szolgáltató (3PL)	Platform ↔ 3PL	Rendelés-átadás (utánvét-összeg, futárszolgáltatás); bolti gyűjtőcsomag-utasítások; várható beszállítás átadása; bevételezés-visszaigazolások; kiszállítási státusz követőszámmal; készletkorrekciók okkóddal; visszáru visszakészletezés/leírás döntéssel; periodikus leltár-egyeztetés; utánvét-elszámolás	Bizonyított konnektor előnyben; ennek híján dokumentált API. Eseményvezérelt, mindkét irányban.
Futárszolgálatok	3PL → Futárok	Csomagátadás, követőszám, státusz	HU: GLS, FoxPost, Packeta, Magyar Posta, DPD, Express One, saját flotta. CZ: Zásilkovna, DPD, GLS. SK: DPD, Packeta, GLS.
Mailchimp	Platform → Mailchimp	Közönség-szinkron, e-kereskedelmi események, kosárelhagyási folyamatok, szegmentációs adatok	Teljes integráció szükséges (arra az esetre, ha a Társaság a Mailchimp megtartása mellett dönt); tranzakciós üzeneteket a platform kezeli. Feliratkozók: ~40 000 HU, ~27 000 CZ, ~4 000 SK. Az ajánlattevő saját e-mail-marketing megoldása külön árazva bemutatható. A SALESmanago kivezethető.
Google Analytics 4	Platform → GA4	E-kereskedelmi mérés (purchase, add_to_cart, stb.)	Új bevezetés — a jelenlegi oldalon nincs érdemi analitika.
Consent management	Platform	Cookie/tracking hozzájárulás-kezelés	GDPR-kompatibilis; az analitikával együtt bevezetendő.
Viselkedés-analitika	Platform → Eszköz	Hőtérképek, session-elemzés	Eszköz az ajánlattevő javaslatától függ (pl. Hotjar, Microsoft Clarity).
eMAG	Platform ↔ eMAG	Terméklistingek, rendelések, készlet	Elvárt képesség, árazandó (C.4, 7. sor), de nem az induláshoz; natív integráció előnyben, ma BaseLinker (feed-alapú) fut. Az árazást/listázást a webshop-csapat végzi a seller centerben.
Temu	Platform ↔ Temu	Terméklistingek, rendelések, készlet	Stabil indulás után; három országra vonatkozó Temu-program, az út és az ár megadásával.
Allegro	Platform ↔ Allegro	Terméklistingek, rendelések, készlet	Stabil indulás után; mindhárom Allegro-oldal (hu/cz/sk). A vevői számlát a platformnak kell kiállítania, amelyet a marketplace továbbít. Készletfrissítés közel valós időben.
Fizetési szolgáltatók	Platform ↔ PSP	Kártyás fizetés, átutalás, utánvét	Devizánként (HUF/CZK/EUR); utánvétes folyamatokkal együtt. Jelenlegi szolgáltató: Globalpay (mindhárom piacon; megtartandó, ha nincs nyomós indok a váltásra). Apple Pay / Google Pay bevezetése kívánatos.
Google / Meta feedek	Platform → Google/Meta	Termékfeed, marketing-események	Analitikai és marketing-feedek.
Laurel CRM (hűségprogram)	Platform ↔ CRM	Kártyaaktiválás és online igénylés, kártya–webshop-fiók összekapcsolás, szint-lekérdezés és automatikus kedvezmény a pénztárnál, pontjóváírás	Csak ha a program megmarad (a döntés a nyertes kihirdetésekor születik); külön árazva (C.4, 16. sor). A CRM marad az elsődleges nyilvántartás, tagadat-migráció nincs, a kasszák nem változnak. Részletek: lent.
BaseLinker	Platform ↔ BaseLinker	Feed-alapú middleware	Ma használatban (feed-alapon); lecserélhető, ha natív integráció elérhető (lásd Tisztázandó).

Interfész-elvárások a két rész között

Az alábbi adatfolyamok a webáruház-platform (2. rész) és a fulfillment-szolgáltató (1. rész) között zajlanak, eseményvezérelten, mindkét irányban:

Adatfolyam	Irány	Leírás
Rendelés-átadás	Platform → 3PL	Utánvét-összeggel és futárszolgáltatással
Bolti gyűjtőcsomag-utasítások	Platform → 3PL	Konszolidált csomagok az üzletekbe
Várható beszállítás átadása	Platform → 3PL	A Beforgból kapott beszállítási adatok továbbítása
Bevételezés-visszaigazolás	3PL → Platform	A várható beszállításokkal szembeni visszaigazolás (mennyiség, beszerzési érték)
Kiszállítási státusz	3PL → Platform	Követőszámmal
Készletkorrekciók	3PL → Platform	Okkóddal
Visszáru	3PL → Platform	Visszakészletezés / leírás döntéssel
Periodikus leltár-egyeztetés	3PL ↔ Platform	A készletkönyv az irányadó
Utánvét-elszámolás	3PL → Társaság	Devizánkénti elszámolás

Kombinált ajánlatnál ezek élesben kerülnek bemutatásra; megosztott odaítélésnél az integráció koordinációját a 2. rész szállítója vezeti. A válaszlevél szerint egy ajánlattevő által bemutatott munkamegosztás megfelel a B.3 pontnak és kiindulási alap; a végleges interfészről az 1. rész nyertesével a szerződéskötési szakaszban döntenek (lásd 07-questions.md → REQ-17). Az 1. rész konnektora egy tipikus REST API illesztés költségével árazandó; az utánvét-elszámolás heti, géppel olvasható kimutatással (CSV/XLSX vagy API) történik, amelyet a platform automatikusan párosít a rendelésekhez.

Hűségprogram — a jelenlegi CRM API (kivonat)

Forrás: 08-loyalty-api-trimmed. Csak akkor releváns, ha a program megmarad.

• Protokoll: JSON-RPC 1.0 HTTP POST-on; minden hívás shopID, tillID és hash (SHA-256 megosztott titkokkal; nincs nonce/időbélyeg — megbízható hálózati integrációként kezelendő). A webshop saját shop/till párként regisztrált.
• Tagazonosító a kártyaszám (nincs e-mail alapú keresés) — a platformnak a kártyaszámot kell tárolnia a vevői fióknál; a kedvezményszinteket a DiscQuery adja, nem kódolhatók fixen.
• Tipikus online checkout: LoyCardQuery (a kosár pontjaival) → kedvezmény megjelenítése → LockCard → fizetés → LoyCardUse (vagy UnlockCard, ha a rendelés elmarad). A zárolás biztosítja az online/offline konzisztenciát.
• Beiratkozás: LoyCardActivation / LoyCardActivationExtended (előre nyomtatott kártya aktiválása), LoyCardUpdate.
• Szinkron/migráció: CardListQuery, CardUpdates (inkrementális), CardTransQuery / PartnerHistoryQuery.

Scope-on kívüli rendszerek

Az alábbi rendszerekhez nem kell integrálni:

• Offline POS rendszerek (HU és CZ)
• Offline ERP (HU és CZ)
• Offline CRM
• Fizikai üzletek kasszarendszerei (csak a hűségprogram API-n keresztüli lekérdezése releváns; a kasszaszoftver a projekt keretében nem módosítható)

Tisztázandó

• Beforg: a formátum eldőlt (JSON, beszállításonként egy fájl, fejléc + teljes cikkrekordok; a német feedet a platform nem dolgozza fel), de az átviteli mód (pull/push), a gyakoriság és az autentikáció szerződéskötéskor egyeztetendő. — REQ-08
• Marketplace-enkénti konkrét integrációs megközelítés (natív / middleware / egyedi) — az ajánlattevők javaslatától függ; ma BaseLinker fut, natív integráció előnyben. Az eMAG-képesség árazandó, az Allegro és a Temu stabil indulás után következik. — REQ-12
• A BaseLinker jelenlegi használata a „nincs élő marketplace-csatorna" állítás fényében. — REQ-15
• A végleges fulfillment-interfész és az 1. rész konnektora — az 1. rész nyertesével egyeztetendő. — REQ-17