Mango.Nop.Plugins/Nop.Plugin.Misc.AIPlugin/docs/EKAER/EKAER_ISSUES.md

EKÁER — Known Issues

Companion to README.md. Topic EKAER, prefix MGFBANKPLUG → entry IDs MGFBANKPLUG-EKAER-I-<RAND> (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 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 (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