17 respuestas en este tema

[cram]

Tengo un programa terminado, pero me consume el coco la idea de haber implementado (una vez más) de forma incorrecta el almacenamiento y la lectura de los códigos internacionales de productos.
Casi se me desarma la aplicación cuando noto que no consideré los artículos de venta fraccionada.
Ya sé que con un buen análisis eso se puede evitar  . Pero el asunto es que a veces paso demasiado tiempo en los análisis y todo evoluciona a tal punto que temino perdiendo el hilo por no acotar bien el sistema.

El asunto es que tengo la siguiente duda:
¿Cómo conviene almacenar el código EAN13 en la base de datos? completo (es decir los 13 dígitos) o solo los 12 primeros y descartar el dígito verificador.
Y el tema viene ligado a los productos fraccionados (normalmente pesables), ya que el dígito verificador cambia cuando cambia el valor del producto, aún cuando se trata del mismo (producto). Es decir, un mismo código pero diferente valor, implica que puede cambiar el dígito verificador (solo por casualidad pueden coincidir).
Cuando un producto pesable pasa por la caja es necesario desarmar el código EAN13, para poder saber si se trata de un artículo internacional o interno fraccionado. Luego, en caso de tratarse de un artículo fraccionado hay que obtener el código interno y el valor. El problema es que si usamos como clave de acceso a los artículos al EAN13, será necesario proporcionar un valor neutro, es decir sin valor o con valor cero (mejor dicho) y esto supone un dígito verificador. Pero si tan solo se modifica la porción del valor en el código ingresado, es probable que el dígito verificador cambie, por lo que no habrá igualdad.
Por otra parte, almacenando solo los 12 primeros dígitos del código EAN13, será necesario descartar el código verificador luego de una lectura aceptada y comparar con el valor clave almacenado. En este caso (al no existir dígito verificador) es posiible cambiar el valor del artículo por cero, sin problemas.

¿Alguien podría darme alguna alternativa eficiente para tratar este problema? 
O sea leer códigos EAN13 de una manera no tan estrambótica.

Gracias.

Aclaro que solucioné el problema guardando dentro del EAN13 un ID del artículo y cambiando la clave de acceso solo para ese caso. Pero no me satisface. Y pretendo conocer alguna forma más eficiente. Por eso acudo a la comunidad.

[egostar]

Hola

¿ Has pensado en la opción de almacenar 12 dígitos en un campo y otro campo con el dígito verificador ?

Es decir, entiendo que tienes presentaciones diferentes de un mismo producto, pero todos llevan el mismo código excepto el dígito verificador, por lo que yo optaría por tener tantos códigos (12 dígitos) como presentaciones de un mismo producto hubiese, pero con su respectivo Dígito Verificador, lo que lo haría una llave única.

Saludos

[cram]

Gracias Egostar,

Es una muy buena opción que no pasó ni remotamente por mi cabeza.
Se puede crear dos llaves, una compuesta y otra simple y listo.

Es más, gracias a esa idea, se me ocurre algo más: se puede desmembrar completamente al EAN13 y rearmarlo según el caso.

A eso llamo una solución elegante... que dicho sea de paso, me faltó pila para llegar a ella (o experiencia). 

Saludos.

[egostar]

Que bien que mi idea te pareció adecuada, me alegra. 

Saludos

[Nikolas]

Tengo 2 clientes con los cuales trabajo de 2 maneras distintas.

cada producto tiene su id además de su codigo de barras:

Para ejemplificar:
- caja de vino x 6u. $120
- bot de vino $20

cliente1 =
tiene 2 codigos por cada presentacion (2 cod int y 2 cod de barras)
cliente2 =
tiene 1 codigo por presentacion (con 2 cod de barras)
en este caso, tambien guardo la unidad x bulto, entonces, si llamo al art por el ean de bulto toma el valor y si llamo el codigo de unidad, toma precio bulto / unidad x bulto. siempre y cdo sea proporcional.

[cram]

Tengo 2 clientes con los cuales trabajo de 2 maneras distintas.

cada producto tiene su id además de su codigo de barras:

Para ejemplificar:
- caja de vino x 6u. $120
- bot de vino $20

cliente1 =
tiene 2 codigos por cada presentacion (2 cod int y 2 cod de barras)
cliente2 =
tiene 1 codigo por presentacion (con 2 cod de barras)
en este caso, tambien guardo la unidad x bulto, entonces, si llamo al art por el ean de bulto toma el valor y si llamo el codigo de unidad, toma precio bulto / unidad x bulto. siempre y cdo sea proporcional.

El ean de bulto que dices ¿es el ean-14, el que se utiliza para paquetes?. Que no es más que un ean-13 con un número antepuesto.
Mi problema es en realidad con los fraccionados, no con los grupos (no es lo mismo). Aun así te agradezco el dato, ya que siempre viene bien.
La mayoría de los comercios implementan la codificación interna en ean-13 (No los comercios chicos por el valor de la impresora).

En el caso de tus ejemplos, me parece correcto el del cliente 2, pero si ellos lo quieren implementar así, que se le puede hacer, ¿no?

La idea de Egostar me pareció buena, puesto que es posible además, de solucionar el problema, ahorrar unos pocos bytes de almacenamiento cuando hay tanto ean-8 como ean-13. Pues los tres primeros dígitos no cambian en absoluto.

Saludos

[Delphius]

Yo nunca estudié eso del EAN13. Y tengo un mar de dudas.
El código es internacional y hay que comprarlos. Eso quiere decir que no se puede estar inventando cualquier numerito. ¿No es así?
Tengo entendido que los 3 primeros identifican al país. Luego los 4 o 5 a la empresa, los restantes al artículo en cuestión y quedando el último como dígito de control. ¿Voy bien?
Si dichos números se compran, eso quiere decir que el organismo internacional ya de por sí establece los números a los artículos.

Voy a hacer una preguntoooonta: ¿El código EAN13 en realidad describe a una DESCRIPCIÓN de UN PRODUCTO o al producto en si? Pongamos un ejemplo clarito. Soy un exportador de arroz y lo comercio internacionalmente. He logrado producir 10 bolsas de arroz de 1kg bajo la marca "El Gauchito". ¿Cada una de las bolsas tiene su código diferente? ¿O es que todas las bolsas tienen el mismo código EAN13 ya que lo que se está identificando es la descripción (la abstracción, o para el purista OO: una clase) y no a una instancia en particular del mismo?
Más ahora, también bajo la marca comercial "El Gauchito" comercio bolsas de 500g ¿Esto es otro producto o más bien es otra presentación del mismo producto?
Supongamos ahora que además de arroz vendo papas con la marca "La pampita". Vendo papasa en bolsas de 50kg, pero también por cajas de 10kg y hasta al minoreo como el almacenero del barrio. ¿Cual es producto?

¿Me pueden explicar a que se refieren cuando el producto es pesable y puede variar el código? ¿Al final me mando cualquiera? Ando muy confundido.

Saludos,

[cram]

En manuales dejé un artículo sobre el tema.
Ingresanndo al sitio de G1, puedes encontrar mucha información.
Pero te comento lo que entiendo:

Es un código internacional normalizado por G1.
Cada país está identificado con uno o más números (según el caso) por números de dos o tres cifras. En el caso de Argentina es 779.
Algunos países como USA, tienen más de un número y en este caso particular pueden tener solo dos cifras iniciales.
Estas tres primeras cifras algunos la denominan bandera (flag), pues en el caso de comenzar con 020-029 losdatos restantes serán de caracter local (o de la organización que los utilice), de ahí que se puede codificar un artículo propio o uno fraccionado usando estos tres números.
Los siguientes nueve números se entienden como par código de fabricante (registrado en el país, para G1) y código de producto (de ese fabricante).
El último número es el dígito de verificación y se calcula usando un algoritmo sencillo.
El algoritmo en Pascal que podés encontrar en la Wikipedia, lo dejé yo a falta de la presencia de un buem lenguaje 

El caso es que para El gauchito, por cada presentación diferente tendrá un código diferente.
Supongamos que el código de "El gauchito" como fabricante es 0254, entonces podría tener esos diez artículos codificados como 00001 a 00010. Y así el código sin dígito verificador sería 779025400001V a 779025400010V.
El código de verificación sirve al escáner de códigos de barra para no ingresar errores.

El caso de los fraccionados se suele codificar usando 020 a 029 como "flag".
Así si el producto "Arroz doble carolina 00000 El gauchito por X Kg." es para la venta fraccionada, se utilizará su código interno, en vez de su código internacional. Supongamos que para cierto mercado es: 0267 y que se utiliza el valor 020 como cabecera.
El código requiere del valor del artículo pesado, así, si un cliente compró 30,75$ de este arroz, el código se veráalgo así como:
020026703075v

Es el software el que debe interpretar ese número y así poder obtener el código interno y el precio total de venta. (No la cantidad, sino el precio). Esto a mí me arroja una inquietud con ciertas monedas, pues tan solo se cuenta con cinco dígitos y poniéndole uno más reduciría la cantidad de dígitos para los códigos internos y habría que utilizar otro u otros valores de cabecera, haciendo muy ruidoso su tratamiento.

Para aquellos artículos pequeños, se utiliza el código de 8 cifras, en el cual cada código pertenece a un pais y no a un fabricante, obviamente debe ser registrado como artículo para ser codificado dde esa manera (con ean-8, o ucc). En esta codificación, no existen las fracciones.

Para el caso de bultos, se le antepone al ean-13 una cifra indicando el tipo de bulto. Y el código se imprime con líneas mucho más grandes, para ser impresos en cartones de menor calidad.

Saludos, Delphius espero que sea comprensible.
Pero como dije hay documentación precisa, sobre el tema.

[Nikolas]

El cogido representa pais / fabrica / producto, si hay otra cosa no es relavante a los fines de programacion.
Lo unico que importe es que es univoco de cada empresa.
SI toman 2 articulos de una misma empresa, veran que solo modifican los ultimos y si toman un mismo producto de distintos paises, se modifican los primeros.

Los problemas que surgen por lo general son:
- cuando el DUN y EAN son iguales.
- cuando se venden articulos que no tienen alguno de ellos.
- cuando cambia y representa el mismo articulo.
Un Ejemplo ficticio:
7790070507099 que es de la yerba cruz de malta x 500 gr
por
7790070507100 yerba cruz de malta sabores del Padro x 500 gr
donde se deja de fabricar el primero.
(En realidad este cambio es para subir implicitacmente el precio)

pd: esto me recuerda las tantas cosas que aprendemos de los rubros de nuestros clientes, daria para abrir un hilo.

[seoane]

Hola,

yo te puedo hablar sobre los programas de supermercado con los que trabajo.

Lo primero es que el codigo de barras nunca puede utilizarse como codigo del articulo (clave primaria) ya que un mismo articulo puede tener varios codigos de barras, he visto casos en que un mismo articulo ha llegado a tener hasta 4 codigos de barras diferentes a la vez (un caso tipico es la cocacola que dependiendo de la fabrica de donde venga cambia el codigo).

Lo mas habitual es tener una tabla de codigos de barras que relacione el codigo de barras con el codigo del producto, si en esa tabla utilizamos como indice el codigo de barras las busquedas son lo bastante rapidas. Ojo aqui con usar el codigo de barras como clave primaria, porque en algunos casos dos articulos diferentes pueden tener el mismo codigo de barras, por ejemplo la ropa, que todas las tallas de un mismo pantalon tienen el mismo codigo y sin embargo no son el mismo producto.

Por ultimo quedan los codigos codigo+peso y codigo+importe. En esos casos lo normal es usar los dos primeros digitos para diferenciar si el codigo es un EAN de un producto o un codigo impreso por una balanza, por ejmplo podemos configurar el programa para que todos los que empiezen por 21 sean del tipo codigo+importe asi cuando leamos un cosigo que empiece por 21 ya o lo buscaremos en la tabla de codigos de barras, sino que lo despiezaremos para obtener el codigo interno y el importe.

En cuanto al digito verificador yo lo tomaria como un numero mas del codigo, no es tu tarea comprobarlo, la mayoria de los escaner (por no decir todos) ya lo hacen por su cuenta.

Saludos

[cram]

Lo primero es que el codigo de barras nunca puede utilizarse como codigo del articulo (clave primaria) ya que un mismo articulo puede tener varios codigos de barras, he visto casos en que un mismo articulo ha llegado a tener hasta 4 codigos de barras diferentes a la vez (un caso tipico es la cocacola que dependiendo de la fabrica de donde venga cambia el codigo).

Lo mas habitual es tener una tabla de codigos de barras que relacione el codigo de barras con el codigo del producto, si en esa tabla utilizamos como indice el codigo de barras las busquedas son lo bastante rapidas. Ojo aqui con usar el codigo de barras como clave primaria, porque en algunos casos dos articulos diferentes pueden tener el mismo codigo de barras, por ejemplo la ropa, que todas las tallas de un mismo pantalon tienen el mismo codigo y sin embargo no son el mismo producto.

Basta con que sea un supermercado o hipermercado. La procedencia de los artículos es múltiple. Un artículo importado y uno de fabricación nacional pueden tener distinto código de barras. Que gran problema ese.
Mencionas el 21. Vi una implementación, que usa el 000, y creo que es un error, ya que está destinado a productos USA. Y se trata de un software que se vende en toda la provincia donde vivo.

No se puede usar como PK es muy cierto. Solo es una especie de "alias numérico" para el mercado internacional. Para colmo, yo me rompí el coco ideando una codificación mnemónica automatizada de la forma 999-99-99 y con el tema del ean, se termina utilizando un ID o un código numérico a secas. 

Seoane, veo que estás unos cuantos pasos adelante. Y me retracto en el asunto de no usar el peso. Es que me refería a mercados pequeños que no tienen forma de dar mucha precisión (o bien no me cabe lo práctico), usando el precio total se solucionan muchos problemas y descarté el uso del precio, pero no es una regla general (como parece en lo que escribí antes). Yo al menos prefiero lisa y llanamente utilizar siempre el precio y deducir la cantidad al tomar el precio unitario del artículo.
Es que tengo muy poca experiencia en su implementación.

Saludos

[Delphius]

En manuales dejé un artículo sobre el tema.
Ingresanndo al sitio de G1, puedes encontrar mucha información.
Pero te comento lo que entiendo:

Es un código internacional normalizado por G1.
Cada país está identificado con uno o más números (según el caso) por números de dos o tres cifras. En el caso de Argentina es 779.
Algunos países como USA, tienen más de un número y en este caso particular pueden tener solo dos cifras iniciales.
Estas tres primeras cifras algunos la denominan bandera (flag), pues en el caso de comenzar con 020-029 losdatos restantes serán de caracter local (o de la organización que los utilice), de ahí que se puede codificar un artículo propio o uno fraccionado usando estos tres números.
Los siguientes nueve números se entienden como par código de fabricante (registrado en el país, para G1) y código de producto (de ese fabricante).
El último número es el dígito de verificación y se calcula usando un algoritmo sencillo.
El algoritmo en Pascal que podés encontrar en la Wikipedia, lo dejé yo a falta de la presencia de un buem lenguaje 

El caso es que para El gauchito, por cada presentación diferente tendrá un código diferente.
Supongamos que el código de "El gauchito" como fabricante es 0254, entonces podría tener esos diez artículos codificados como 00001 a 00010. Y así el código sin dígito verificador sería 779025400001V a 779025400010V.
El código de verificación sirve al escáner de códigos de barra para no ingresar errores.

El caso de los fraccionados se suele codificar usando 020 a 029 como "flag".
Así si el producto "Arroz doble carolina 00000 El gauchito por X Kg." es para la venta fraccionada, se utilizará su código interno, en vez de su código internacional. Supongamos que para cierto mercado es: 0267 y que se utiliza el valor 020 como cabecera.
El código requiere del valor del artículo pesado, así, si un cliente compró 30,75$ de este arroz, el código se veráalgo así como:
020026703075v

Es el software el que debe interpretar ese número y así poder obtener el código interno y el precio total de venta. (No la cantidad, sino el precio). Esto a mí me arroja una inquietud con ciertas monedas, pues tan solo se cuenta con cinco dígitos y poniéndole uno más reduciría la cantidad de dígitos para los códigos internos y habría que utilizar otro u otros valores de cabecera, haciendo muy ruidoso su tratamiento.

Para aquellos artículos pequeños, se utiliza el código de 8 cifras, en el cual cada código pertenece a un pais y no a un fabricante, obviamente debe ser registrado como artículo para ser codificado dde esa manera (con ean-8, o ucc). En esta codificación, no existen las fracciones.

Para el caso de bultos, se le antepone al ean-13 una cifra indicando el tipo de bulto. Y el código se imprime con líneas mucho más grandes, para ser impresos en cartones de menor calidad.

Saludos, Delphius espero que sea comprensible.
Pero como dije hay documentación precisa, sobre el tema.

A ver, digamos ahora que en lugar de esas 10 bolsas que he producido en realidad tengo 100 tonelada de arroz, por lo que llenaría exactamente 100x1000 bolsas. Si efectivamente es como lo dices (lo que te resalté en negrita) no me alcanzan los números para cubrir toda mi producción. Porque si hay que uno por cada cosa... el EAN13 debió haberse roto hace ya un buen rato.

Nuevamente mi pregunta: ¿EAN identifica a una descripción de algún producto o al producto? Porque no es lo mismo. Yo cada vez que puedo llamo a la atención en este punto.

Y no me queda claro del todo porque en todos lados usan la palabra producto. Y no he visto alguna documentación que aclare justamente en ese punto. Ni que decir, algún texto que diga si realmente la parte que identifica al "producto" la asigna el organismo o si a eso lo pone el comerciante/productor/vendedor/loquesea.

El cogido representa pais / fabrica / producto, si hay otra cosa no es relavante a los fines de programacion.
Lo unico que importe es que es univoco de cada empresa.
SI toman 2 articulos de una misma empresa, veran que solo modifican los ultimos y si toman un mismo producto de distintos paises, se modifican los primeros.

Los problemas que surgen por lo general son:
- cuando el DUN y EAN son iguales.
- cuando se venden articulos que no tienen alguno de ellos.
- cuando cambia y representa el mismo articulo.
Un Ejemplo ficticio:
7790070507099 que es de la yerba cruz de malta x 500 gr
por
7790070507100 yerba cruz de malta sabores del Padro x 500 gr
donde se deja de fabricar el primero.
(En realidad este cambio es para subir implicitacmente el precio)

pd: esto me recuerda las tantas cosas que aprendemos de los rubros de nuestros clientes, daria para abrir un hilo.

Creo que es más que obvio que dentro para un mismo proveedor/productor/loquesea de un país tendrán los mismos identificadores iniciales y diferirá en lo que hace a "productos".

Por si aún no han captado: me voy al super y compro dos sachés de leche descremada libre de gluten y con vitaminas B3 marca "La Serenísima" de 1l. La pregunta es ¿Ambos tienen el mismo número EAN13? ¿O cada saché tiene uno diferente? Yo he visto a cajeras del super que pasan la lectora por uno solo y luego ellan ingresan la cantidad de "items". ¿Que significa esto? 

También ya que estoy en el super y es el día de la oferta en carnes me dirijo a la sección carnicería. Pido los máximos 4kg de bife de lomo que me dejan llevar. La señora pasada en años que sigue en la cola se lleva otros 4kg de bife de lomo. Pregunta: ¿El EAN13 ahora es para la vaca entera, el corte de alguna carne de ésta, o específico a cada compra que haga? ¿La vieja se está llevando el mismo EAN que yo?

¿Me explico?
Cuando digo que no leo es porque la que ya leí no me aclara estas dudas. 

Saludos,

[seoane]

También ya que estoy en el super y es el día de la oferta en carnes me dirijo a la sección carnicería. Pido los máximos 4kg de bife de lomo que me dejan llevar. La señora pasada en años que sigue en la cola se lleva otros 4kg de bife de lomo. Pregunta: ¿El EAN13 ahora es para la vaca entera, el corte de alguna carne de ésta, o específico a cada compra que haga? ¿La vieja se está llevando el mismo EAN que yo?

El mundo de los codigos de barras es una pesadilla muy "interesante". Lo tipico en las carnicerias es que las balanzas tengas programado un codigo para cada producto que pesan (normalmente 5 digitos) y al pesar imprimen una etiqueta con un codigo de barras como este: 21 CCCCC IIIII D donde 21 se usa para hacerle saber al programa de caja que este es un codigo que vamos a tener que desglosar (puede ser cuarlquiera ente el 20 y el 25 ya que estan reservados y ningun codigo de barras de un producto empezara por esos digitos), luego tenemos 5 digitos con el codigo del producto, otros 5 con el importe y el digito de control que calcula automaticamente la balanza.

En ejemplo anterior usamos codigo+importe pero podriamos usar codigo+peso, se suele usar codigo mas importe porque si por algun motivo (redondeo, diferencia en el precio, etc) la caja no calcula el importe igual que la balanza, aunque solo sea un centimo, el cliente se enfada (hay gente muy quisquillosa). Por otro lado si usamos codigo+peso, podemos tener la carne etiquetada durante mas tiempo, incluso aunque cambie el precio. Las dos formas tienen sus pros y contras.

Por ultimo queda la manera que utilizan los grandes hipermercados SS TTTTT IIIII D donde SS identifica la seccion (carniceria, pescaderia, etc ...) TTTTT es el numero de ticket/etiqueta y IIIII es el importe. En estos sitios las balanzas estan conectadas por red a un servidor central que recibe la informacion de todas las etiquetas, y solo imprimen una etiqueta por cliente, por ejemplo, te puedes llevar unas chuletas y unos bistecs y telo menten todo en una misma bolsa con una sola etiqueta. Cuando pasas por caja, el ordenador se conecta al servidor central y por el numero de etiqueta localiza que articulos llevas y los detalla en el ticket. Pero lo mejor es que si el sistema esta "caido", por ejemplo porque no hay red, siguen pudiendo cobrar ya que introducen la venta en la seccion que corresponde (SS) por el importe que corresponde (IIIII) y asi sale detallado en el ticket "Carniceria 10 €".

Lo dicho un mundo 

[Delphius]

Bueno, ya voy entendiendo... para cosas fracionadas como las carnes por ejemplo hacemos de cuenta una cosa que parece escapar a la regla. Son excepciónes. Y me da a entender que lo que se busca aquí es que efectivamente sea inequívocamente a un producto.

Pero esto no elimina toda la cuestión con esta palabrita que parese ser bastanta poliforma, volvamos al caso de la leche. Me compré 2 sachés de la la misma marca, misma descripción, misma presentación. ¿Ambas tienen el mismo EAN?
Porque si hay que ponerle un propio identificador a cada cosa posible de fabricar y vender es más que obvio que no bastan 5 numeritos para cubrir las posibilidades ¿O no?
¿Cuántas cajas, sachés, y/o paquetes de leche se fabrican por minuto en el mundo? Lindo trabajito el tener que ir contandolos...

Me rehúso a creer que sea por producto. G1 se hace la guita. Cada empresa del mundo le paga anualmente la cuota para tener esos numeritos y esta le remite millones de copias de código de barras para cada porquería que venda.
¿Y si mejor definimos lo que entendemos por producto? 

Saludos,

[cram]

Delphius,
Los códigos no tienen nada que ver con las existencias, solo con la determinación de un artículo (que puede haber fácilmente mil o dos mil o más en un establecimiento y todos tendrán el mismo código). Así, si tienes una existencia de 2500 Kg. de azúcar en bolsas de 1 Kg. de la misma marca, presentación, fabricante y país (es decir el mismo artículo seriado) todos tendrán el mismo código.

Algunos puntos de venta implementan el N x y luego pasan el artículo en el escáner, ya que si el cliente pasa con diez artículos iguales, solo bastará con pasar uno y multiplicarlos por 10. Algunos cajeros prefieren pasar cada uno de los artículos (total, no pagan el rollo).

Yo trabajé para un hipermercado, pero no tenía ni idea de como funcionaba esto (ya hace unos trece años), recuerdo que en aquel entonces empecé a estudiar Java. Se pasaban los códigos a las básculas junto a sus precios y denominaciones, todo desde un servidor. Ponerlos a manos puede ser muuuuuy tedioso, sobre todo cuando tienes unas cuantas y éstas están mojadas con carne descongelada, etc. (y los operarios son  ). Estas maquinitas (muy caras, por cierto) tienen una impresora en la cual se coloca un rollo de etiquetas engomadas para adherirlas a los paquetes y al menos las que conozco, imprimen un código EAN-13.

SI bien G1 supongo que recibe dinero por mantener los códigos, etc. No recibe dinero por cada artículo pasado en una caja (al menos no creo que así sea), pues no se como llegaría esa información a ellos (procesar semejante caudal de información sería un despropósito para todos, dado su costo).

Por eso, te aclaro una vez, no se diferencias uno de otro paquete cuando son idénticos (no se cuenta la serie).

El propósito de la codificación es hacerlo fácil para los vendedores al momento de procesar una venta y salida de artículos. Pero además existen códigos para logística como el EAN-14 y algunos sensores con microcircuitos que permiten escanear el contenido de todo un contenedor al paso. todo en una pasada por una antena  .

En fin, implementé una solución basada en lo que me sugiere Egostar y de paso separé un poco más, así algún día se puede aggregar información de procedencia, etc.
La implementación cuenta con una tabla de EAN13 y otra de EAN8 (que por razones prácticas no logré juntarlos)

• una referencia al artículo
• los tres primeros dígitos del código (esto está mal, pues en determinados casos se utilizan dos cifras)
• el código
• el dígito de verificación

Bueno, algo así. De última si se me complica mucho, hago sin modificaciones a la sugerencia separando 12 y 1 y listo.

Saludos

[Delphius]

Cram, yo fui DBA en un supermercado hace unos años, entiendo perfectamente que el EAN-13 hace a la descripción de un producto o artículo. Tuve que agarrar un carrito y empezar a hacer el alta de cada descripción de artículos habidos. Espero nunca más tener que hacer eso.    Aunque me habían quedados algunos puntos por comprender del EAN. Más esperaba que con mis palabras se notara que a lo que ustedes se esfuerzan en llamar artículos o producto no lo es. Sino que es la descripción.

Es fundamental poner los puntos en las ies porque a las palabras artículo y producto las usamos tan a la ligera y debiéramos hacer notar que es realmente lo que pretende decir.
Suena ilógico que el EAN-13 tuviera que estar identificando cada cosa que se fabrique, pero luego viene el novato al foro y lee artículo y en lo primero que piensa es cada cosa tiene uno y no en que se está identificando a la descripción de la cosa. Es un error que lo he visto desde que comencé en los foros. Error que proviene desde la enseñanza académica porque en los ejercicios no se le pide que hilen tan fino. Entonces salen convencidos que una botella de Coca Cola de 1l es un articulo o producto y otra botella también de 1l de Coca Cola la ven como otro más. Entienden que si bien ambos describen a lo mismo, cada uno es unico. No se percatan de eso sino es hasta que tienen que unir conceptos de OO con bases de datos y las reglas normales le dicen que esa información común a los artículos puede ir en otra tabla. Y allí dicen ¡Ha... mirá vos. Había una entidad escondida en el DER y no la veía!

Se toma tan a la lijera a esa palabra que luego ya de grandes uno la dice y repite y no se da cuenta que en realidad lo que está diciendo es la descripción. Hay casos en lo que asumimos que es obvio en realidad no lo es.

Parte de esta discusión lo puse en evidencia en otro hilo, cuando se discutió sobre sistema de stock en diferentes unidades y equivalencias. Y me llama la atención de al parecer se ha ignorado mis palabras y no se ha aprendido nada de ellas sobre cuando algo es un producto y cuando no lo es. 

Saludos,

[cram]

Así es Delphius. Las diferencias son importantes. Por eso escribía producto y de fabricante, aunque en los últimos mensajes usé la palabra artículo, por que la usaron y se me hizo que sería más cómodo así.
Aún así, a mí me da igual. Pero puede resultar un error en determinados casos.
Aún así artículo es la segunda acepción para producto de compra/venta. No hay mucho inconveniente.

En sentidos más amplios se puede hablar de mercadería, mercancía, etc.
Aunque de ahora en más intentaré ser más específico y escribiré producto.

Gracias por la aclaración, ahora pienso leer el hilo que mencionas.
Al menos me sacaste el susto de creer que no entendías lo que se decía... 

Saludos.

[cram]

Al final, para volver al tema de la implementación, quedó como la primer y buena sugerencia de Egostar.

Separé el código de su dígito verificador y por otra parte creé un procedimiento (procedimiento almacenado) que genera el dígito de verificación para una cadena ingresada, tanto EAN-8, como EAN-13.
Esto me permite comparar solo la primer parte (es decir el código real), ya que el trabajo de la verificación hace el escáner.
Así, cuando encuentre un pesable, puedo reemplazar los últimos cinco dígitos por cero y el mismo procedimiento de búsqueda o bien desarmar el código y buscar su ID (como lo venfgo haciendo), como quede mejor.

La aclaración de Seoane es muy importante en este caso. Ya que no se puede guardar los códigos EAN en la tabla de artículos, al menos en una DB normalizada. Por esta razón es necesario crear una tabla aparte para cada código y relacionarlo a la tabla de artículos.

Saludos