Hvis du nogensinde har prøvet at forbinde en RFID-vaskesnor til et ERP- eller WMS-system, kender du allerede problemet: læserne spytter en strøm af tag-læsninger ud, men dit ERP-system ønsker rene, kedelige og forretningsklare optegnelser.
Så lad os tale om nøgledatafelter der får integrationen til rent faktisk at fungere, plus et par rigtige vaskeri-arbejdsgange (hotellinned, hospitalstøj, uniformudlejning), hvor disse felter betaler regningerne.
Og ja – det er også her, valget af mærke betyder noget. En UHF-tekstiletiket opfører sig meget anderledes end en hård PPS-knapetiket. Vores fabrik (CXJ Smart Card) bygger begge dele, plus de indlæg og kodning, der forhindrer dine masterdata i at blive et rod.
Dit ERP/WMS ønsker ikke, at "EPC læses 57 gange på 2 sekunder." Det ønsker "“Modtog 120 stykker ved Dok A”" eller "“Sorteret til Kunderute 12.”
Derfor mellemvare sidder i midten. Den filtrerer dubletter, grupperer læsninger, anvender regler og leverer rene resultater forretningsarrangementer Dit ERP/WMS kan bogføres som transaktioner. Dette mønster vises i EPC-arkitektur (ALE-stil filtrering/gruppering) og i moderne RFID middleware-opgørelser.
Eksempel på rigtig tøjvask:
En tunnellæser ved "jordsorteringsudgang" ser det samme mærke flere gange, mens en pose ryster igennem. Middleware deduplicerer dette og udsender én hændelse som: SORTED_OUT @ 10:23:11.
Den enkelte hændelse er det, du knytter til WMS: flytteordre, ændring af lagerstatus, eller bekræftelse af produktionstrin.
Ingen kortlægning, ingen sandhed. Punktum.
Du har brug for en unik tag-identifikator (ofte EPC til UHF), der linker til din ERP/WMS-masterrecord: vare-/aktiv-ID, SKU, kundeejede varer (COG)-kode eller hvad dit system nu kalder det. EPC-fokuserede UHF-systemer følger typisk Gen2/ISO 18000-63-økosystemet, så du får interoperabilitet på tværs af læsere og tags.
Hvad går i stykker, når man springer dette over:
Fra vores side hjælper vi normalt kunder med at definere en kodningsplan (UID/EPC/NDEF/nøgler) og verifikationstrin, så tags ankommer klar til registrering i ERP.
Hvis du kun gemmer "tag findes", kan du ikke køre handlinger. Du skal bruge hvor + hvornår + hvilket stadie kombination:
Standarder som GS1 EPCIS modeller dette eksplicit med felter som begivenhedstid, læsepunkt, og virksomhedslokation (og CBV-ordforråd for trin/dispositioner).
Brugsscenario for hotellinned:
Rengøringspersonalet skriger "mangler håndklæder". Jeres driftsteam tjekker ERP og ser:
RFID-vaskeriløsninger fremhæver også ofte "unik tag + realtidsmængde + historiksporing", fordi det medfører færre tab og færre manuelle optællinger.
Vasketøj handler ikke bare om "hvor er det". Det handler også om "“hvor tilberedt er den.”
To felter har stor betydning:
Disse understøtter regler for tilbagetrækning ("smid det ud efter X cyklusser"), kvalitetskontrol og svindkontrol. Diskussioner om vasketøjsregistrering fremhæver ofte vaskeantal og reduktion af tab/tyveri som centrale resultater.
Eksempel på hospitalstøj:
Du sætter en regel: efter tilstrækkeligt hårde cyklusser går skrubbere ned i "nedgradering" eller "pensionering". Hvis du ikke gemmer vaskeantal, ender du med at gå på pension for sent (risiko) eller for tidligt (spild). Uanset hvad, gør det ondt.
Og ja, livscyklushistorikken hjælper også, når en kunde påstår, at "du aldrig returnerede mine varer". Du kan vise kæden. Simpelt og rent.
Det er her, pengediskussionen finder sted.
RFID-hændelser bør rulles ind i ERP/WMS-objekter som:
Hvis dit ERP/WMS ikke kan afstemme leverancer og returneringer, bliver RFID blot et dashboard. Du ønsker, at det skal drive: tilbageførsler, SLA-rapportering og færre tvister.
Middleware-til-ERP-vejledning advarer gentagne gange om, at rå læsninger overbelaster virksomhedsapps, medmindre de først konverteres til meningsfulde hændelser.
Nedenfor er en praktisk feltliste, som du kan give til dit ERP/WMS-team. Jeg bruger "event"-sprog, fordi det skalerer bedre end "læserlogfiler".“
| Feltgruppe | Feltnavn (eksempel) | Idé til ERP/WMS-kortlægning | Eksempelværdi | Kildenøgle |
|---|---|---|---|---|
| Identitet | Tag-ID / EPC | Aktiv-ID ↔ EPC-kort | urne:epc:id:sgtin:... | S3 |
| Stamdata | Vare/SKU/Aktivtype | Varemaster | “"Badehåndklæde / 400 g"” | S5 |
| Ejendomsret | Kunde / Kontrakt / COG | Kundemaster | “Hotel A / Kontrakt 2026” | S5 |
| Behandle | Forretningstrin / Status | WIP-trin / lagerstatus | sortering, vasket, pakket | S1 |
| Beliggenhed | Læsepunkt / Biz-lokation | Lagerlokation / -zone | “"Anlæg_A_Tunnel_02"” | S1 |
| Tid | Begivenhedstidspunkt (tidsstempel) | Bogføringstid / revisionstid | 2026-01-20T10:23:11-08:00 | S1 |
| Mængde | Antal i begivenheden | Lagerdelta | +120 | S2 |
| Livscyklus | Antal vaskecyklusser | Attribut / tæller | 37 | S4 |
| Historie | Bevægelses-/brugshistorik | Sporbarhedslog | begivenhedsliste | S4 |
| Opretholdelse | Reparationsflag / bemærkning | Vedligeholdelsesrapport | “"lappet søm"” | S5 |
| Undtagelser | Manglende/overforbrug/timeout-flag | Undtagelseskø | MANGLER_EFTER_SORTERING | S2 |
Kildenøgle (for troværdighed):
Integration er ikke kun software. Hvis tags fejler under reelle vaskforhold, bliver dine datafelter fiktion.
Fra vores katalog er de produktkategorier, der optræder mest i vaskeri- + ERP/WMS-projekter:
Med andre ord: vælg det tag, der overlever din vaskekemi + varme + tryk + mekanisk påvirkning, og lås derefter kodningen, så EPC → ERP-kortlægning forbliver stabil. Vores linjer i Shenzhen udfører one-stop-bygning + 100% udgående inspektion, så piloter kan skalere uden drama med "nye batcher læses anderledes".
