

Un recuento físico es contar a mano lo que hay en el depósito y compararlo con lo que dice el sistema.
Existe porque ningún sistema sabe lo que pasa en un estante: solo sabe lo que alguien registró.
Entre esas dos cosas siempre hay una distancia, y el recuento es lo único que la mide.
El recuento total cuenta todo el depósito de una vez, en general con la operación frenada.
Tiene la ventaja de dar una foto completa y coherente, y la desventaja de que cuesta caro y por eso se hace poco.
El recuento cíclico cuenta una porción por vez, todas las semanas, sin frenar nada.
Detecta las diferencias mucho más rápido, y por eso suele funcionar mejor en operaciones activas.
No todos los productos merecen la misma frecuencia.
Lo habitual es contar más seguido lo que más vale y lo que más se mueve.
Un puñado de artículos suele concentrar la mayor parte del valor del inventario, y ahí es donde el error duele.
Los artículos baratos y de poca rotación se pueden contar una o dos veces al año sin ninguna culpa.
Una práctica que cambia el resultado es no mostrarle a quien cuenta el saldo esperado.
Cuando la planilla trae el número del sistema impreso, la mente lo confirma en vez de contar.
Contar a ciegas es más lento y da un dato mucho más confiable.
Una diferencia detectada no se corrige de inmediato sin mirarla.
Antes conviene recontar el artículo, porque buena parte de las diferencias son errores de conteo y no faltantes reales.
Si se confirma, recién ahí se registra el ajuste, y con el motivo escrito.
La cifra que importa no es cuánto faltó sino qué porcentaje de los artículos contados dio distinto.
Ese indicador es una radiografía del depósito: si empeora mes a mes, el problema está en cómo se registra y no en quién cuenta.
Un recuento que no cambia ninguna práctica es plata gastada en confirmar un número.
Las exigencias formales de inventariar y la periodicidad requerida cambian según el país y el tipo de empresa.
Conviene confirmarlas con un contador local antes de fijar el calendario, y no asumir que lo de un país aplica a todos.
Conviene decirlo derecho: no existe un objeto de recuento físico en el ERP.
No hay hoja de conteo, no hay campo de cantidad contada y no hay comparación automática contra el saldo teórico.
El conteo se hace fuera del sistema y su resultado entra como corrección.
La diferencia se aplica sobre el campo Stock del registro de Stock, que combina un almacén con un producto.
O sea que el recuento y el ajuste de inventario terminan en el mismo lugar.
El historial del registro guarda quién cambió el valor y cuándo, aunque no guarde que ese cambio vino de un recuento.
Una Vista de lista sobre el objeto Stock filtrada por almacén sirve como planilla de salida.
Ordenarla por producto y exportarla da la hoja con la que se recorre el depósito.
Para contar a ciegas conviene sacar la columna de cantidad de esa vista antes de exportarla.
Un depósito de repuestos hace recuento cíclico todos los viernes, sobre una familia distinta cada semana.
Exporta la Vista de lista del almacén filtrada por esa familia, sin la columna de stock.
Cuenta, vuelve y compara contra lo que muestra la pantalla.
Los artículos que dan distinto se recuentan, y los confirmados se corrigen uno por uno con el motivo anotado.
Un objeto de recuento guardaría la fecha, el almacén, quién contó, la cantidad contada y la teórica, y calcularía la diferencia solo.
También permitiría medir el porcentaje de exactitud del inventario a lo largo del tiempo, que es el indicador que de verdad importa.
Nada de eso está construido hoy, y el ERP está en desarrollo activo, así que esa ausencia describe el estado actual.
No como documento propio: no hay objeto de recuento ni hoja de conteo.
Lo que se registra es el resultado, corrigiendo el campo Stock de cada registro afectado.
La trazabilidad de esa corrección queda en el historial del registro.
El cíclico funciona mejor en operaciones activas, porque detecta la diferencia semanas antes y no frena el depósito.
El total sigue teniendo sentido cuando hace falta una foto completa a una fecha determinada.
Muchas empresas hacen los dos: cíclico durante el año y total al cierre.
Contra el stock físico, que es lo que debería estar en el estante.
La Cantidad disponible no sirve para eso porque ya tiene descontado lo reservado, y lo reservado sigue estando físicamente.
Confundir las dos magnitudes genera diferencias que no existen.
Depende del valor y de la rotación: lo caro y lo que más se mueve, más seguido.
Un criterio práctico es contar los artículos de mayor valor varias veces al año y el resto una o dos.
Las exigencias formales de inventariar cambian según el país, así que conviene confirmarlas localmente.
No existe ningún objeto de recuento de inventario en la organización de desarrollo.
Se verificó sobre los 102 objetos personalizados con prefijo EGAFutura__ y sobre todos los campos personalizados, buscando los patrones Recuento, Count, Ajuste y Adjust.
El resultado fue cero coincidencias aplicables a inventario.
Existe EGAFutura__Inspeccion__c, con etiqueta Inspección, pero no tiene ninguna relación con el stock.
Sus búsquedas apuntan a EGAFutura__Activo_fijo__c, EGAFutura__Orden_mantenimiento__c, EGAFutura__Incidente__c, EGAFutura__Area_funcional__c y EGAFutura__Ubicacion__c.
O sea que pertenece al circuito de mantenimiento de bienes, y usarlo como recuento mezclaría dos procesos distintos.
El único destino posible hoy es EGAFutura__Stock__c, sobre EGAFutura__Warehouse_Stock__c.
Es numérico de 16 enteros sin decimales, así que no admite fracciones, algo a considerar en depósitos que miden por peso.
El objeto tiene 17 campos en total y 7 personalizados, y su único campo obligatorio es la relación principal-detalle EGAFutura__Warehouse__c.
EGAFutura__AvailableQuantity__c es un campo fórmula, y no es contra ese número que se compara lo contado.
Cada corrección recalcula EGAFutura__Total_Stock__c, que es un campo de resumen de tipo suma sobre Almacén.
En un recuento total eso significa tantos recálculos como registros corregidos, algo a tener en cuenta al planificar una carga masiva.
Existen EGAFutura__Warehouse_Stock__History y EGAFutura__Warehouse_Stock__ChangeEvent, así que el objeto admite historial de campos y eventos de cambio.
El objeto no tiene tipos de registro definidos.
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 un objeto de recuento describe el estado de hoy y no una limitación definitiva.