Un servidor para inventario y logística debe sostener operaciones correctas, no sólo abrir pantallas rápido. Si una recepción se registra dos veces, una reserva se pierde o un despacho queda pendiente sin aviso, añadir memoria no demuestra que el problema esté resuelto. Primero hay que seguir el movimiento y saber dónde cambió su estado.

Esta guía propone una prueba de aceptación para tu sistema: recepción, reserva, despacho y conciliación. Sirve para evaluar una instalación nueva, una migración o un incidente repetido. No establece mínimos universales de hardware ni promete inventario exacto por contratar una nube. El resultado útil es evidencia que puedan revisar juntos almacén, responsable del software y proveedor de infraestructura.

Ve directo a: recorrido de prueba · ejemplo con cantidades · ficha de conciliación · criterios de aceptación.

1. Separa lo físico, lo registrado y lo pendiente

Antes de medir velocidad, acuerda el significado de las cantidades. La existencia física se verifica en el almacén; el saldo del sistema resulta de movimientos y reglas de negocio. Una reserva puede reducir lo disponible para vender sin sacar todavía una pieza del edificio. Una transferencia puede estar en tránsito y no disponible en el destino. Cuarentena, devoluciones y unidades de medida añaden otras reglas que deben documentarse.

También hay eventos pendientes: una terminal puede haber capturado una operación sin que el sistema central la confirme. No mezcles ese estado con una transacción completada. Si la interfaz muestra el mismo mensaje para ambos, el operador no sabe si debe esperar, consultar o escalar. Volver a pulsar «guardar» no es una prueba segura de que la primera solicitud falló.

El estándar GS1 EPCIS organiza la captura y el intercambio de eventos de visibilidad entre aplicaciones y empresas. Es una referencia útil para pensar qué ocurrió, cuándo y dónde, pero no obliga a todos los negocios a implementarlo ni certifica la exactitud del inventario. Un evento con un identificador correcto todavía puede describir una cantidad capturada incorrectamente.

2. Sigue un movimiento completo, no una pantalla aislada

Realiza el recorrido en un entorno de prueba autorizado, con productos y documentos ficticios. El responsable del software debe definir qué estados y acciones admite su versión. No pruebes desconexiones, reintentos ni cambios de saldos sobre pedidos reales.

1. Preparar: selecciona un producto, almacén, ubicación y unidad de medida. Registra saldo inicial, reservas y documentos abiertos. Conserva la hora con zona horaria y una referencia única del caso.
2. Recibir: captura una entrada y comprueba documento, cantidad y ubicación. Distingue la hora de captura de la confirmación central. Revisa que el lector no haya enviado dos veces el mismo código por configuración o uso.
3. Reservar: asigna una parte a un pedido. Comprueba qué saldo cambia y qué ve otro operador autorizado. La definición de «disponible» debe ser la del sistema, no una fórmula supuesta.
4. Despachar: confirma una salida parcial. Verifica la relación con la reserva, el documento de salida y, si aplica, la etiqueta o guía. Generar una etiqueta no demuestra por sí solo que se haya descontado el inventario.
5. Conciliar: compara los movimientos confirmados con el saldo final y el estado de las integraciones. Cierra o explica cada evento pendiente. Conserva los resultados, incluidos los errores, no sólo el tiempo más rápido.

En cada salto pregunta quién confirma la operación: la aplicación, un proceso en segundo plano o un servicio externo. Si interviene una API de transporte o comercio electrónico, solicita su comportamiento documentado frente a errores y reintentos. No supongas que todas aceptan una clave de idempotencia o conservan esas claves durante el mismo periodo.

3. Ejemplo hipotético: una recepción no debe contarse dos veces

Ejercicio ilustrativo, no resultado de un cliente. Partimos de 100 unidades registradas y utilizables, sin reservas, tránsito ni cuarentena. En este modelo simplificado, disponible equivale a saldo registrado menos reservas. Las reglas de tu aplicación pueden ser diferentes.

El último renglón describe el resultado de negocio que se quiere validar, no una capacidad que toda API incluya. El sistema debe reconocer o controlar la repetición conforme a su diseño; no debe crear silenciosamente otra entrada de 20 unidades. Si no existe deduplicación documentada, el procedimiento de recuperación necesita revisión del proveedor antes de habilitar reintentos automáticos.

La conciliación aritmética es 100 +20 −5 =115. Las 2 unidades reservadas siguen dentro de ese saldo; restarlas otra vez para calcular la existencia registrada sería un error. Si un conteo físico encuentra 114, hay una diferencia de−1 por investigar. Eso no demuestra que el servidor haya perdido un dato: revisa conteo, ubicaciones, unidades, movimientos sin capturar y cortes de tiempo antes de atribuir la causa.

4. Prueba dos operadores y una respuesta que no llega

Dos personas pueden consultar el mismo saldo y actuar casi al mismo tiempo. La aceptación debe comprobar qué ocurre cuando ambas intentan reservar las últimas unidades: rechazo claro, espera o resultado permitido por las reglas del sistema. Una captura de pantalla individual no revela ese conflicto.

Como ejemplo técnico específico, la documentación de aislamiento de transacciones de PostgreSQL describe distintas visibilidades de datos y situaciones en las que una transacción debe reintentarse. Su documentación de bloqueos explícitos explica controles de concurrencia y posibles esperas. Esto no significa que tu sistema use PostgreSQL ni que debas cambiar su aislamiento: esas decisiones corresponden al diseño y soporte de la aplicación.

Otro caso importante es perder la respuesta después de enviar una operación. Puede haber sido aplicada aunque el cliente no haya recibido confirmación. El piloto debe comprobar cómo se consulta su estado por una referencia y cómo se evita repetirla indebidamente. Un tiempo de espera agotado no autoriza a descontar o sumar existencias manualmente.

Si el programa ofrece trabajo sin conexión, prueba su sincronización y resolución de conflictos según la documentación. Si no lo ofrece, define un procedimiento operativo de contingencia; no presentes una cola local improvisada como modo offline compatible. La reconexión debe terminar en estados conocidos, no en una lista de operaciones «probablemente enviadas».

5. Ficha de conciliación para copiar al expediente

Esta ficha desplegable no envía ni guarda datos. Cópiala a un documento interno autorizado. Usa identificadores ficticios en pruebas y evita publicar existencias, clientes, rutas o credenciales.

Abre la ficha de conciliación del movimiento

• Fecha, hora y zona horaria: ____
• Versión del sistema y entorno de prueba: ____
• Producto, unidad, almacén y ubicación ficticios: ____
• Referencia única del caso y documento de origen: ____
• Saldo inicial y reservas iniciales: ____
• Entradas confirmadas / salidas confirmadas: ____
• Transferencias, ajustes u otros estados incluidos en el corte: ____
• Saldo final esperado / observado: ____ / ____
• Eventos pendientes, rechazados o duplicados: ____
• Hora de captura / confirmación / aparición en reporte: ____
• Evidencia del sistema y responsable que la revisó: ____
• Diferencia explicada, corrección autorizada y repetición del caso: ____

Para el caso simple sin otros movimientos: saldo esperado = saldo inicial + entradas confirmadas − salidas confirmadas. No uses esta simplificación para omitir ajustes, tránsito o reglas que sí existan en tu operación.

6. Dimensiona con carga representativa y periféricos reales

Un inventario con pocos usuarios puede generar muchas operaciones mediante importaciones, tiendas o dispositivos. Otro con muchos usuarios puede pasar gran parte del día consultando. Para elegir capacidad, registra operaciones activas, tamaño de base, crecimiento, tareas de cierre y consultas concurrentes. Compara tiempos y errores con la misma carga, no sólo CPU o RAM contratadas.

Incluye lectores, impresoras de etiquetas, básculas y terminales que realmente se usarán. Comprueba controladores, conexión local o remota, permisos y salida física de la etiqueta. Una sesión remota que abre el ERP no demuestra que el periférico necesario funcione. Exige al fabricante requisitos y versiones compatibles antes de comprar infraestructura.

Separa el momento de confirmación transaccional del refresco de un reporte. Un panel puede consultar una réplica, una caché o un proceso periódico si la aplicación lo implementa. Registra esa demora y su efecto operativo; no prometas consistencia instantánea por añadir un tablero. Si el síntoma aparece principalmente entre sedes, sigue también el diagnóstico de latencia para oficinas remotas.

7. Decide con condiciones de aceptación escritas

• Exactitud del caso: movimientos confirmados y saldo esperado concilian; diferencias pendientes tienen causa y responsable, no un ajuste oculto.
• Concurrencia: dos operadores obtienen un resultado compatible con la regla de negocio y un mensaje comprensible cuando existe conflicto.
• Reintentos: el caso repetido no produce doble contabilización silenciosa; se conoce cómo consultar el estado y recuperar un resultado incierto.
• Integraciones: cada envío tiene evidencia de aceptación, rechazo o pendiente y un procedimiento de seguimiento.
• Rendimiento: el tiempo máximo aceptable se acuerda para la tarea y carga concretas, incluyendo errores y casos lentos. No se sustituye por un promedio aislado.

El soporte experimentado aporta valor cuando interpreta esos registros y coordina aplicación, almacén, red e infraestructura. Una mensualidad menor puede salir cara si tu equipo dedica horas a perseguir movimientos sin trazabilidad. Compara alcance, responsables y tiempos de atención documentados. Ni un servidor más caro ni un socio técnico reemplazan la disciplina operativa del almacén.

8. IA útil sin convertir una sugerencia en un movimiento

La IA puede ayudar a agrupar errores, encontrar patrones de incidencias o proponer qué casos revisar en datos autorizados y minimizados. Debe trabajar con referencias verificables y distinguir anomalía de causa. Un producto con alta rotación no es prueba de fraude, y un cambio de demanda no autoriza a alterar una compra.

No conectes una recomendación directamente con ajustes de saldo, cancelaciones o aprobación de pedidos sin controles específicos. Contrasta sus propuestas con documentos y conteos; conserva revisión humana y permisos apropiados. El criterio final sigue siendo operativo: cada unidad y cada movimiento deben poder explicarse, no sólo visualizarse.