EAN / UPC

[nova]

top dat nu ook het EAN nummer kan toegevoegd worden aan een product. Echter hebben veel producten geen EAN maar een UPC code. ik neem gemakshalve aan dat het de bedoeling is deze dan als EAN in the vullen.

top werk, en hoop dat dit snel wordt uitgebreid naar de mogelijkheid om op EAN/UPC te zoeken en te sorteren.

[Longbeard]

UPC komt binnenkort bij het product submitten te staan. Het veld is er al met nog enige andere velden. Wanneer deze optie er komt valt nu nog niet te zeggen, dat ligt eraan wanneer de devvers tijd tijd hiervoor hebben.

[ACM]

Bij deze, EAN kon al, UPC nu ook, hoewel je er niet expliciet op kan zoeken, het zit gewoon bij het keyword-dingetje meegenomen

[nova]

Wellicht een leuke toevoeging aan de pricewatch een Webcam EAN Scanner.
http://en.barcodepedia.com/

[Laurent]

Overigens zijn de verschillen tussen UPC en EAN-13 niet heel erg groot geloof ik. Maar inderdaad, één nummertje meer of minder maakt wel een verschil bij het zoeken.

[Verwijderd]

Wellicht is het een idee in de database enkel de broncode op te nemen? Al dit soort dingen komen tot stand uit een berekening van een bronwaarde. Hierdoor krijg je de vrijheid het altijd aan te bieden in welke eindvorm dan ook, door simpelweg de berekening aan te passen / toe te voegen. (Zolang een bronwaarde zich leent voor de berekening natuurlijk, maar dat is sowieso geldig voor de initieel bedoelde codering)

Maakt het wel handig natuurlijk ook de omgekeerde berekening toepasbaar te maken bij het invoeren, indien alleen een al berekende code direct beschikbaar is. Afhankelijk van de eindwaarde kan zelfs automatisch de codesoort bepaald worden (niet overal).

[ Voor 23% gewijzigd door Verwijderd op 19-07-2007 22:41 ]

[nova]

Verwijderd schreef op donderdag 19 juli 2007 @ 22:37:
Wellicht is het een idee in de database enkel de broncode op te nemen? Al dit soort dingen komen tot stand uit een berekening van een bronwaarde. Hierdoor krijg je de vrijheid het altijd aan te bieden in welke eindvorm dan ook, door simpelweg de berekening aan te passen / toe te voegen. (Zolang een bronwaarde zich leent voor de berekening natuurlijk, maar dat is sowieso geldig voor de initieel bedoelde codering)

Maakt het wel handig natuurlijk ook de omgekeerde berekening toepasbaar te maken bij het invoeren, indien alleen een al berekende code direct beschikbaar is. Afhankelijk van de eindwaarde kan zelfs automatisch de codesoort bepaald worden (niet overal).

De broncode waaruit de EAN/UPC is ontstaan?

[ACM]

Verwijderd schreef op donderdag 19 juli 2007 @ 22:37:
Wellicht is het een idee in de database enkel de broncode op te nemen?

Als ik je goed begrijp: Denk je niet dat die broncode per producent zal verschillen en afhangt van meer dan alleen de producten die wij hier tonen, danwel van meer dan alleen de productinformatie waar wij als consument over kunnen beschikken?

[Verwijderd]

De meeste coderingen (voor o.a. barcodes) ontstaan via een vaste berekening. Als je b.v. een EAN code invoert, weet je 100% wat de invoer is geweest. Hetzelfde geldt voor de andere codes. Of je nu de bronwaarde of het resultaat na omrekening in de database opneemt, verandert niets aan de inhoud. Wel maakt het het mogelijk makkelijk dezelfde bronwaarde te gebruiken om in een andere vorm weer te geven.

Neem bijvoorbeeld de welbekende interleave (ITF): bronwaarde is "12345" resultaat is "*12345*". Wil je vervolgens zaken weergeven in een andere code, kan dat met "*12345*" nog steeds natuurlijk, maar dan ga je eerst terug naar bron. Als je dat via berekening wil doen, moet je wel eerst zeker weten met welke codering de waarde in de database is gezet om terug te rekenen, en dan te herberekenen naar een nieuwe code.

Ik zit me overigens net te realiseren dat bij EAN/UPC de bronwaarden eigenlijk in weinig andere situaties bruikbaar zijn (Landcode, bedrijfsgegevens) . In geval van andersoortige data zoals productnamen of adressen die in een streepjescode worden opgenomen (tbv o.a. verzending) is dat natuurlijk een ander verhaal. De zin van het opslaan in bronwaarden is in dit geval dus redelijk beperkt. Hooguit kan je er eenvoudiger mee zoeken naar producten van dezelfde fabrikant, of gemarkeerd voor hetzelfde land.

Ik denk dat de constructie om klaar te zijn voor bronwaarden alleen interessant is, als er een bruikbare toepassing is binnen onze gegevens om andersoortige coderingen uit te kunnen voeren. Op dit moment zie ik daar niet zoveel toepassing voor.

Wij hebben bij ons in de printindustrie te maken met dienstverleners die soms meerdere codes moeten uitvoeren of met wijzigingen te maken krijgen, vandaar dat er bij mij redelijk is ingestampt aan te raden met bronwaarden te werken in de databases

[SA007]

btw, upc-a = ean13 met een 0 als eerste cijfer.

Wat code om een barcode te controleren of hij klopt: (zelf gemaakt, werkt voor ean8/ean13/upc-a/isbn)

PHP:

  function barcode_check_checksum ($type, $code) {
    switch($type) {
      case("ISBN")   : $code = isbn_to_ean_13($code); break;
      case("EAN-8")  :
      case("UPC-A")  : $code = '0' . $code;
      case("EAN-13") : break;
      default: return;
    }
    return (substr($code, -1, 1) == barcode_checksum("EAN-13",substr($code, 0, -1))); break;
  }

  function barcode_checksum($type, $code) {
    switch($type) {
      case("ISBN")   : $code = isbn_to_ean_13($code); break;
      case("EAN-8")  :
      case("UPC-A")  : $code = '0' . $code;
      case("EAN-13") : break;
      default: return;
    }
    for ($count = 1; $count < strlen($code); $count+=2) $total += $code[$count];
    $total *= 3;
    for ($count = 0; $count < strlen($code); $count+=2) $total += $code[$count];

    return (10 - $total % 10) % 10;
  }

  function isbn_to_EAN_13 ($isbn) {
    for ($i=0;$i<strlen($isbn);$i++)
    {
      $ascii_code=ord($isbn[$i]);
      if ($ascii_code >=48 && $asci_code <=57) continue;
      $isbn = cutchar($isbn,$i);
      $i--;
    }
    $isbn = "978" . substr($isbn,0,9);
    return $isbn . barcode_checksum("EAN-13", $isbn);
  }

Is een ontderdeel van dit scriptje wat ik ooit gemaakt heb:
http://shared.sa007.nl/barcode/