EGA Futura » Capacitación y Soporte
Un número de serie es un código que identifica a una unidad y a ninguna otra.
Dos televisores del mismo modelo salidos de la misma fábrica el mismo día tienen números de serie distintos.
Esa unicidad es todo el punto: permite hablar de ese aparato y no de ese modelo.
Permite saber a quién se le vendió una unidad concreta y en qué fecha.
Permite validar una garantía sin discutir, porque la fecha de compra queda atada al código.
Permite reconstruir el historial de reparaciones de un equipo, que es lo que decide si conviene arreglarlo o cambiarlo.
Y permite detectar un equipo robado o una unidad que nunca debería haber salido del depósito.
La pregunta práctica es si vale la pena distinguir una unidad de la de al lado.
En un tornillo no vale, en una notebook sí, y en un frasco de crema alcanza con el lote.
El criterio habitual es el valor unitario y la existencia de garantía o servicio técnico.
Seriar obliga a registrar el código en cada movimiento: al recibir, al transferir y al vender.
Un depósito que mueve mil unidades por día no puede seriar sin lectura de código de barras.
Cuando el registro se hace a mano, la práctica se abandona sola en pocas semanas.
El número de serie lo asigna el fabricante y viene con el producto.
Muchas empresas agregan además una etiqueta interna propia, con su propia numeración y su propio formato.
Tener los dos separados es lo que permite reetiquetar un bien sin perder la referencia del fabricante.
El código de barras identifica al modelo: todas las unidades iguales comparten el mismo.
Los códigos EAN, UPC, ISBN y MPN pertenecen a esa familia y no sirven para distinguir unidades.
Confundirlos es un error frecuente y caro, porque lleva a creer que ya hay trazabilidad unitaria cuando no la hay.
El ERP tiene número de serie, pero en un solo lugar: el objeto Activos fijos.
Ahí sirve para identificar los bienes que la empresa usa, como computadoras, rodados, maquinarias y herramientas.
La mercadería del inventario, en cambio, todavía no se puede seriar.
El campo es de texto y admite hasta 120 caracteres, suficiente para cualquier codificación de fabricante.
Tiene restricción de unicidad, así que la Plataforma no deja guardar dos activos con el mismo número.
Esa unicidad no distingue mayúsculas de minúsculas, o sea que un mismo código escrito de dos formas cuenta como repetido.
El campo no es obligatorio, porque hay bienes que simplemente no traen número.
Además tiene seguimiento de historial activado, así que un cambio de número queda registrado con fecha y autor.
Junto al número de serie convive la Etiqueta de Activo, que es el código que pone la propia empresa.
El primero lo trae el fabricante y el segundo lo decide la organización.
Los dos son únicos, así que hay dos caminos distintos para detectar un duplicado.
El objeto Stock lleva cantidades por almacén y producto, sin ningún campo que identifique unidades.
Tampoco lo tienen la línea de transferencia ni la línea de venta.
Para vender productos seriados hoy habría que modelarlo con objetos personalizados, y conviene medir ese trabajo antes de comprometerlo.
Una empresa de sesenta personas quiere saber qué notebook tiene cada quien.
Carga cada equipo como activo fijo con su número de serie de fábrica y su etiqueta interna.
Cuando alguien reporta una falla, el número de serie lleva directo a la fecha de compra y a la garantía.
Una Vista de lista ordenada por vencimiento de garantía anticipa qué equipos van a quedar sin cobertura.
Hoy no de forma nativa: el número de serie vive en Activos fijos y no en el inventario.
Ni el stock, ni la línea de venta, ni la línea de transferencia tienen un campo para identificar unidades.
Resolverlo exige objetos personalizados creados en cada organización.
La Plataforma rechaza el segundo registro, porque el campo tiene restricción de unicidad.
Esa validación no distingue mayúsculas de minúsculas, así que dos grafías del mismo código chocan igual.
Es la causa más frecuente de error en una carga masiva de bienes.
No: el código de barras identifica al modelo y lo comparten todas las unidades iguales.
El número de serie identifica una sola unidad y no se repite.
Los campos EAN, UPC, ISBN y MPN del producto pertenecen a la primera familia.
No, el campo admite quedar vacío.
Se dejó opcional porque hay bienes que no traen número, como los muebles o un inmueble.
Cuando el bien sí lo trae, conviene cargarlo, porque es lo que sostiene el reclamo de garantía.
El campo es EGAFutura__Numero_serie__c y existe sobre un solo objeto: EGAFutura__Activo_fijo__c.
Se verificó recorriendo todos los campos personalizados de la organización, y no hay ningún otro campo de serie en objetos de EGA Futura.
La única coincidencia adicional es SLASerialNumber__c sobre Account, que no pertenece al ERP.
Es de tipo texto de 120 caracteres.
Tiene unique en verdadero y caseSensitive en falso, o sea unicidad sin distinguir mayúsculas.
Tiene required en falso, así que admite nulo.
Tiene trackHistory en verdadero: los cambios quedan en el historial del registro.
Conviene notar que externalId está en falso, así que no sirve como clave de actualización externa sin antes marcarlo.
Su texto de ayuda es Número de serie provisto por el fabricante.
EGAFutura__Etiqueta_Activo__c es texto de 32 caracteres con la misma restricción de unicidad.
Los dos conviven porque responden a dueños distintos: la etiqueta la pone la empresa y la serie la trae el fabricante.
Product2 tiene 16 campos personalizados de EGA Futura y ninguno es de serie.
EGAFutura__Warehouse_Stock__c tiene 7 campos personalizados, todos de cantidad, de referencia o de umbral.
EGAFutura__StockTransferLine__c y EGAFutura__SalesOrderLine__c tampoco tienen ningún campo identificador de unidad.
Todo lo anterior se verificó contra la organización de desarrollo el 8 de agosto de 2026.
El ERP de EGA Futura está en construcción, así que la ausencia de serie en el inventario describe el estado de hoy y no una limitación definitiva.