Welke standaard voor lineaire (eendimensionale) barcodes kunnen we het beste gebruiken voor ordernummers?

Ean 13 of 8 is de meest gebruikte en dus ook best ondersteunde barcodeformaat in Europa.
Je dient echter wel rekening te houden met enkele “standaard” beperkingen.
- Bij EAN13 dient de code 12 tekens lang te zijn (de 13de is een check getal). Bij EAN 8 is dat 7 tekens.
- Om geen conflict te krijgen met externe barcode reeksen dient de barcode in de 20-reeks te zitten. Oftewel met 2 te beginnen

Deze twee punten stellen dus eisen aan de lengte van je ordernummers.

Bij welk formaat dan ook, er dient rekening gehouden te worden met de standaarden. Anders zal je vroeg of laat geconfronteerd worden met beperkingen of conflicten met externe barcodes.

Hoe ziet een ordernummer er momenteel uit?

Het ordernummer is nu een decimaal getal, maar dat kunnen we omprogrammeren.

We gebruiken al twee barcodes: een EAN-13 voor artikelen en omdozen (hebben een afwijkend EAN) plus een KIX (RM4SCC) voor een Nederlands adres. Voor ordernummers zoek ik daarom eigenlijk een andere barcodestandaard.

Hoeveel ruimte heb je voor de barcode, en wat voor materiaal hebben je ombouwdozen?

Waarschijnlijk gebruiken jij of je logistieke partner een fotoscanner (aangezien je RM4SCC KIX inzet), is dat het geval dan kan je kijken naar een Aztec Matrix of een andere 2D codering voor je ordernummers. Wel krijg je dan iets met een kanon en een mug.

Persoonlijk zou ik er voor gaan om voor ombouwdozen over te gaan op Interleaved 2 of 5 (is beter leesbaar op golfkarton dan EAN13) en de EAN13 of 8 in te zetten voor mijn ordernummers.

Ik ben benieuwd naar je oplossing.

Gr, Remko

Het zijn geen ombouwdozen maar omdozen, dozen met meerdere exemplaren van hetzelfde artikel. Daarvoor heb ik geen nieuwe barcode nodig, want de omdozen hebben al af-fabriek een sticker met EAN-13. Dat de EAN-13 van de omdoos verschilt van de EAN-13 van het artikel in de doos is onhandig, maar hebben we simpel opgelost met twee extra databasevelden.

Het gaat me inderdaad om een barcode voor het ordernummer die liefst zichtbaar afwijkt van andere barcodes (EAN-13 en KIX). Is bijvoorbeeld Code 39 niet de flexibelste oplossing? Veel data hoeven we niet kwijt, want het ordernummer wordt gebruikt als primaire sleutel voor het ophalen en updaten van een record.

Gekke ik, had ik een heel ander beeld bij een omdoos.

Code 39 is een optie, 43 tekens zal meer dan voldoende zijn volgens mij. Echter:

... het ordernummer wordt gebruikt als primaire sleutel voor het ophalen en updaten van een record

standaard Code 39 heeft *geen* controlecijfer. Het gebruik ervan brengt dan ook een risico met zich mee. Wees er dus zeker van dat je Code 39 mod 43 gebruikt. Deze heeft wel een controlecijfer, maar de barcodescanner van jou en/of je logistiek partner moet er wel geschikt voor zijn (het zal je verbazen hoeveel hedendaagse barcodescanners het niet kunnen lezen...)

Code 128C kan een andere optie zijn (?).

Gr, Remko

Remko, dank je. We gaan het inderdaad eerst maar eens goed testen.

Interessant, kun je eens iets meer vertellen over hoe je er mee werkt?

A. Loomans schreef:Interessant, kun je eens iets meer vertellen over hoe je er mee werkt?

Dat is een lang verhaal, maar je zou het kunnen samenvatten als: ik wil de droomoplossing bouwen voor een logistieke nachtmerrie. En omdat ik stronteigenwijs ben, wil ik die ook nog zelf bouwen. Puntsgewijs:

1. Om te beginnen moeten we EAN-barcodes gaan scannen, niet alleen die van losse artikelen, maar ook die van omdozen met meerdere exemplaren van hetzelfde artikel. We moeten nu te vaak te lang zoeken: je weet wel uit je hoofd in welke gang een artikel ligt, maar niet precies in welke stellingkast of op welke plank. Dat wordt dus: artikel x ligt in gang 2, stelling 3, plank 4.

2. Ons magazijn wordt te klein, dus we gaan hier de handvoorraad voor enkele dagen aanhouden en de rest elders opslaan. Dan wordt het nog ruimer: artikel x ligt in magazijn 1, gang 2, stelling 3, plank 4.

3. We moeten FIFO (first in, first out) werken voor bijvoorbeeld artikelen met "batteries included". De oudste artikelen met de oudste batterijen moeten het eerst de deur uit.

4. Het lossen van pallets met nieuwe voorraad is een vergelijkbare nachtmerrie. Levering vergelijken met pakbon, pakbon vergelijken met inkooporder en alles in het magazijn zetten gaat vele malen sneller als we de EAN-barcodes van omdozen kunnen scannen.

5. Omdat ik het graag meteen goed oplos, wil ik ordernummers apart kunnen scannen. Veel bestellingen bestaan namelijk uit meerdere artikelen, dus er is een één-op-veel-relatie tussen ordernummer en EAN. Je gaat niet meerdere EAN's scannen als je ook één ordernummer kunt scannen. En als alle artikelen eenmaal zijn ingepakt, is alleen nog het ordernummer echt belangrijk.

6. Omdat hoofdonderdelen van onze webwinkels real-time voorraadinformatie gebruiken, loopt het voorraadbeheer via een externe databaseserver. De logistieke informatie loopt daarom via webinterfaces, wat vooral voor het printen van barcodes met de juiste toleranties een uitdaging is.

Op dit moment voer ik tests uit met de Barcode Generator for PHP. In combinatie met wat CSS3 en Firefox lijkt die vrij aardig op te gaan leveren wat we uiteindelijk nodig hebben.