101 javaslat egy kupacban túl sok egy kézi átnézéshez, ráadásul nagyon eltérő
mérlegelést igényelnek: a "Békás Kft." és a "Békás Kft" között nincs mit
eldönteni, a "Dénes Natura" és a "Dénes Natura Kft" között viszont van.
- ProducerDeduplicator::differenceCategory(): a LEGKEVÉSBÉ agresszív átalakítás,
ami már egy kulcsra hozza a csoport tagjait - csak írásjel / egybeírás /
ékezet / cégforma / vegyes.
- a riport ebben a sorrendben írja ki a csoportokat (elöl a gyakorlatilag
eldöntött esetek), és a "csak írásjel" kategóriánál előre beírja a javaslatot;
a többinél a végleges név üresen marad, a javaslat a Megjegyzés oszlopban.
A d2d másolaton: 14 csak írásjel (előre kitöltve, azonnal végrehajtható),
7 egybeírás, 8 ékezet, 72 cégforma - utóbbi 87 vár a megrendelő döntésére.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A takarítás első köre után is maradtak nyilvánvaló duplikátumok: "Békás Kft." /
"Békás Kft", "Gast Food" / "Gast-Food", "Alföldi Tej" / "Alfölditej". A
NameNormalizer csak a kis/nagybetűt, a / és _ szeparátort és a többszörös
szóközt kezeli - az írásjelekhez, a kötőjelhez, az egybeíráshoz és az
ékezethez nem nyúl.
A szabályt SZÁNDÉKOSAN nem lazítottuk, mert két, ellentétes igényű feladatot
szolgál ki: az import-párosításnál egy téves egyezés csendben rossz gyártóhoz
rendelne termékeket, a takarítási javaslatnál viszont a megrendelő nemet mond
rá. Ezért a kettő szétválik.
- ProducerDeduplicator::looseCandidateGroups(): megengedőbb kulcs (írásjel,
ékezet, szóköz elhagyása) KIZÁRÓLAG javaslatokhoz. A különböző cégformát
(Kft vs Zrt) itt sem vonja össze - az valódi különbség, nem elírás -, a
cégforma nélküli név viszont párba állhat, ha csak egyféle forma van.
- producers:dedupe-report --loose: a javaslatok "ellenőrizendő" típussal, ÜRES
végleges névvel kerülnek a lapra, a javaslat a Megjegyzés oszlopban. Így az
alapértelmezett viselkedés a "nem nyúlunk hozzá", a döntés tudatos kitöltés.
- buildPlan: az üres végleges név mostantól KIHAGYÁS, nem hiba - ez a javaslat
elutasításának módja. A kihagyott csoportokat a parancs tételesen kiírja.
- buildPlan bármely aktív gyártót elfogad a lapon, nem csak a szigorú
duplikátumok tagjait.
A d2d másolaton az első kör után: 0 biztos duplikáció, 101 ellenőrizendő
javaslat 241 rekorddal.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A megrendelő 2026-08-27-én hat esetben jelezte, hogy két külön névcsoportunk
valójában ugyanaz a cég: a rövid név és a cégformás név (Kőröstej / Kőröstej
Kft, Pick / Pick Szeged Zrt, White Lake / White Lake Kft, ...). A
névnormalizálás ezt nem tudhatja, mert a nevek érdemben különböznek.
- buildPlan a LAP "Csoport" oszlopa szerint csoportosít, nem az adatbázis
normalizálása szerint. Így a lap szélesebb csoportot is kijelölhet - a
végrehajtásba nem kell csoportokon átívelő logika.
- validateGrouping: a lap szélesebb csoportot csinálhat, SZŰKEBBET nem. Ha az
azonos nevű rekordok külön csoportba kerülnének, a végén két azonos nevű
gyártó maradna, vagyis pont a duplikációt állítanánk elő. Ilyenkor a csoport
kimarad a végrehajtásból, nem csak figyelmeztetés.
- a megtartott REKORD továbbra is a legtöbb terméket tartalmazó (a legkevesebb
sor mozdul), a NEVE viszont a választott cégnév
2 új teszt a csoportokon átívelő összevonásra és a szétszórás elutasítására.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A megelőzés után a már felhalmozódott adat takarítása: 70 duplikált névcsoport,
146 rekord, ebből 76 beolvasztandó.
Két parancs, mert a kivezetés három környezeten megy (local -> d2d -> éles), és
minden környezetnek SAJÁT duplikátum-készlete van - a döntési lapot ezért ott
kell újragenerálni, nem beégetett ID-listával dolgozunk.
- producers:dedupe-report — döntési xlsx a megrendelőnek. A megtartandó a
legtöbb TERMÉKKEL rendelkező rekord (döntetlennél több rendelési tétel, majd
régebbi rekord); a végleges nevet a megrendelő hagyja jóvá, mert 48 csoport
csak kis/nagybetűben tér el, és az írásmód üzleti döntés.
- producers:dedupe — alapból csak kimutatás, --apply hajt végre.
A lapot FEJLÉCNÉV alapján olvassa, nem oszlopbetű szerint, így a megrendelő
beszúrhat oszlopot vagy átrendezheti a lapot anélkül, hogy eltörne.
Hiányos csoportot és ismeretlen azonosítót visszautasít.
- Visszafordíthatóság: a jelentés SORONKÉNT tárolja a régi producer_id-t, mert
a fordított leképezés azokat a sorokat is átírná, amelyek eredetileg is a
megtartott rekordra mutattak. --rollback ebből állít vissza.
- Tartós nyom a jelentésfájltól függetlenül: a beolvasztott rekord archive +
canSee=0 lesz, és a note-jába kerül, hova olvadt be.
- A két nagy táblán nincs index a producer_id-n, ezért táblánként EGY UPDATE
fut CASE leképezéssel - 76 külön WHERE 76 teljes scant jelentene.
Mért eredmény a d2d másolaton: 27 mp alatt 314 termék + 27 272 archív + 115
árlista-sor átírva; a vizsgált árlistán a "Módosult" sorok 126 -> 23, a
gyártó-diffek 114 -> 2. Visszagörgetés után minden szám visszaállt, és az
újraszámolt diff ismét 126 - az ok-okozat mindkét irányban igazolt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
