# EKÁER — Known Issues > Companion to [`README.md`](README.md). Topic `EKAER`, prefix `MGFBANKPLUG` → entry IDs `MGFBANKPLUG-EKAER-I-` (issue) / `-B-` (confirmed bug). > ID format, Status vocabulary, type codes and archival → `../../.github/TOPIC_CODES.md` (→ framework registry). Scope: a FruitBank EKÁER-bejelentés szerver-oldali / nopCommerce-integrációs problémái — VTSZ-forrás, adatmodell-megfeleltetések, NAV-hívás kiszolgálása. ## Active entries ## MGFBANKPLUG-EKAER-I-T3X8: A `Product.Gtin` átmenetileg a VTSZ-t tárolja — szétválasztandó **Status:** Open · **Priority:** P3 · **Type:** I (adatmodell / átmeneti megoldás) > **Újranyitva (2026-06-15):** a probléma **továbbra is fennáll** — a `Gtin` jelenleg is a VTSZ-t tárolja, a szétválasztás nem történt meg. A 2026-06-02-i `FBANKAPP-DMODEL-I-P6X4`-be (DATAMODEL) helyezés visszavonva; a követés ITT (EKÁER) folytatódik. *(A `FBANKAPP-DMODEL-I-P6X4` ennek megfelelően lezárva — DATAMODEL.)* Az EKÁER `tradeCardItem.productVtsz` (kötelező, 8 jegyű vámtarifaszám) forrása jelenleg a nopCommerce **`Product.Gtin`** oszlop (a `ProductDto.Gtin`-en keresztül). A GTIN és a VTSZ **fogalmilag különböző**: - **GTIN** — globális kereskedelmi cikkszám (vonalkód-azonosító, EAN/UPC). - **VTSZ** — vámtarifaszám (a termék vám-/statisztikai besorolása). Egy termékhez a kettő nem azonos; a `Gtin` oszlop VTSZ-ként való használata **átmeneti** megoldás az EKÁER-integráció beindításához. **Hatás:** jelenleg nincs üzemszerű gond (a `Gtin` mező szabad, és a VTSZ-t tölthetjük bele). Hosszú távon viszont, ha a valódi GTIN-re is szükség lesz, a kettő ütközik. **Javítási irány (hosszú táv):** külön `Vtsz` mező/`GenericAttribute` a `Product`-on, és a `ShippingToEkaerMapper` onnan olvasson — a `Gtin` maradjon a valódi GTIN. **Affected:** - `FruitBank.Common/Dtos/ProductDto.cs` → `Gtin` property (a `[Column(nameof(Product.Gtin))]` jelöléssel, summary-ban megjelölve) - jövőbeli: `ShippingToEkaerMapper` (`FruitBank.Common/Services/Ekaer/`) — a `productVtsz`-t a külön `Vtsz` mezőből olvassa ## MGFBANKPLUG-EKAER-I-F5D9: Küszöb alatti külföldi reláció kötelezőként kezelve — ügyfél-kérés, a hatályos jognál szigorúbb **Status:** Open · **Priority:** P2 · **Type:** I (üzleti szabály vs jogszabály) · **2026-07-10** **A hatályos jogszabály:** a 13/2020. (XII. 23.) PM rendelet **4. § i)** pontja szerint mentes a fuvarozás, ha „egy fuvarozás keretében egymillió forint értéket és ötszáz kilogramm bruttó tömeget meg nem haladó, bejelentésköteles termékkel ugyanazon feladótól ugyanazon címzett részére ugyanazon gépjárművel" történik — a mentesség szövegében **nincs irány-megkötés**, tehát a küszöb alatti fuvar **importnál/exportnál SEM** kötelező (szó szerint ellenőrizve, net.jogtar, 2026-07-10). **A jelenlegi viselkedés — KIMONDOTTAN AZ ÜGYFÉL KÉRÉSE:** minden külföldről bejövő szállítmány **küszöbtől függetlenül** bejelentendő (`EkaerReportability` — küszöb alatt is `Required`, ha a feladó és a címzett országkódja eltér). Ez a jogszabályi minimumnál szigorúbb, önkéntes bejelentés — az ügyfél tudatos döntése. **Miért van nyitva:** az ügyfél várhatóan utánanéz a kérdésnek, és **nem kizárt, hogy a közeljövőben az eredeti (hatályos) jogszabályi szabályra kell átírni**: küszöb alatt → `NotRequired` iránytól függetlenül; ezzel a kapu országkód-alapú `DataError`-ága is okafogyottá válik (az országkód-hibát a generate-validálás úgyis blokkolja), az `EkaerReportability` jelentősen egyszerűsödik. **Ha az átírás megtörténik, VELE EGYÜTT kezelendő:** [`EKAER_TODO.md`](EKAER_TODO.md) **T-H7F2** (depot-szintű küszöb-aggregálás — szintén vállalt eltérés a jogszabályi aggregálási egységtől, ugyanahhoz a kapu+UI átíráshoz tartozik). **Affected:** - `FruitBank.Common/Services/Ekaer/EkaerReportability.cs` — a (2)-(3) ág (országkód-validálás + külföldi → Required) - `docs/EKAER/README.md` — kapu-szakasz (a döntés után a bullet frissítendő) - Kapcsolódik: `EKAER_TODO.md` K7Q2 #11 (Closed — ide mutat) ## MGFBANKPLUG-EKAER-I-B2W7: Partner/PartnerDepot: nincs Phone/Email mező — magyar felrakodási helynél kellene **Status:** Open · **Priority:** P3 · **Type:** I (adatmodell — jelenleg NEM aktuális) · **2026-07-10** A NAV a **magyarországi felrakodási helynél** a `LocationType` `phone`/`e-mail` mezőit is kéri (a séma szerint opcionálisak, a NAV-felület kéri) — a bejövő felrakodási hely nálunk a `Partner`/`PartnerDepot` címe, ezekben az entitásokban viszont **nincs Phone/Email mező**. **Miért nem aktuális (2026-07-10, user):** Partner és PartnerDepot **jelenleg csak külföldi beszállítóhoz** létezik → a felrakodási hely mindig külföldi → phone/email nem kell. A hiány csak akkor válik valóssá, ha (a) **belföldi** beszállító kerül a rendszerbe (magyar felrakodási hely), VAGY (b) az **automata NAV-beadás** bekötésekor a teljes cím-adatkör kötelezővé válik. Addig: kézi beadásnál az ügyintéző a NAV-felületen pótolhatja. **Javítási irány (ha aktuális lesz):** `Phone` + `Email` oszlop a `PartnerDepot`-on (és/vagy Partneren), admin-felület, `ShippingToEkaerMapper.BuildLocation` bekötés. **Affected:** - `FruitBank.Common/Entities/PartnerDepot.cs` (+ `Partner.cs`) — jövőbeli Phone/Email oszlopok - `ShippingToEkaerMapper.BuildLocation` (`FruitBank.Common/Services/Ekaer/`) — a mezők leképezése - Kapcsolódik: `EKAER_TODO.md` K7Q2 #6 (seller-mezők) ## MGFBANKPLUG-EKAER-I-K9J4: Kimenő lerakodási hely: hiányzó házszám (streetNumber) és Phone/Email — az automata beadás előfeltétele **Status:** Open · **Priority:** P2 · **Type:** I (adatmodell + mapping) · **2026-07-10** > ⚠️ **Az automata NAV-beadás KÖVETELMÉNY lesz** (user, 2026-07-10) — a kézi XML-feladás csak átmenet, amíg nincs teszt-hozzáférés. Ezek a hiányok tehát nem „későbbi finomítások", hanem az automata út előfeltételei. A kimenő (belföldi vevős, `D` irányú) tradeCard **lerakodási helye** az `OrderSiteSnapshot`-ból (fallback: a vevő fő címéből) épül. Ami megvan: név, adószám, országkód, irányítószám, város, utca. Ami **hiányzik**: 1. **Külön házszám (`streetNumber`)** — a NAV a `street` + `streetNumber` mezőpárt (vagy helyrajzi számot: `lotNumber`) várja kötelezően; nálunk a házszám a `Street` stringben egyben van („Fő utca 12."). Utólagos string-parse megbízhatatlan → **a snapshot-készítéskor** kell külön mezőbe tenni (a nop `Address.Address1/Address2` bontásából), és a `BuildSiteLocation` / `BuildCustomerLocation` képezze le. 2. **Phone/Email** — a snapshotban és a vevő-cím leképezésben sincs; a sémában opcionális, a NAV-felület kéri. A forrásadat létezik: nop **`Address.PhoneNumber`** → a snapshot bővíthető vele felvételkor. Kézi beadásnál egyik sem blokkol (az ügyintéző a NAV-felületen pótolja) — az automata beadásnál a hiányos cím `TC_LOCATION_NOT_COMPLETE`-et adhat. **Affected:** - `FruitBank.Common/Entities/OrderSiteSnapshot.cs` — `StreetNumber` + `Phone` (+ `Email`?) mezők; a snapshot-készítő kód (Address → snapshot) - `ShippingToEkaerMapper.BuildSiteLocation` / `BuildCustomerLocation` (`FruitBank.Common/Services/Ekaer/`) — leképezés - Kapcsolódik: [`I-B2W7`](EKAER_ISSUES.md) (bejövő oldali Phone/Email — ott Partner/Depot), `EKAER_TODO.md` K7Q2 #5 (MapShipping-drift — szintén automata-előfeltétel) ## MGFBANKPLUG-EKAER-I-M6Y2: A számla-pénznem a Partnerből jön — jobb lenne a ShippingDocument-en **Status:** Open · **Priority:** P3 · **Type:** I (adatmodell) Az EKÁER tétel-érték HUF-ra számításához a forrás-pénznem jelenleg a **`Partner.Currency`**-ből jön (a beszállító alap-devizája). **Most 100%-ban megbízható** — a partner egyértelműen meghatározza a devizát. **Hatás:** működik; de a pénznem **konceptuálisan a szállítmányhoz / dokumentumhoz tartozik**, nem a partnerhez (egy partner elvileg többféle devizában is számlázhat). **Javítási irány:** külön **`Currency` oszlop a `ShippingDocument`-en**, és az `EkaerValueCalculator` / `ShippingToEkaerMapper` onnan olvasson; a `Partner.Currency` maradjon fallback. **Nem prioritás** — a jelenlegi partner-alapú forrás elegendő. **Affected:** - `FruitBank.Common/Entities/ShippingDocument.cs` — jövőbeli `Currency` oszlop - `FruitBank.Common/Services/Ekaer/EkaerValueCalculator.cs` + `ShippingToEkaerMapper.cs` — a deviza-forrás - jelenlegi forrás: `PartnerBase.Currency`