# Pruebas de operación antes de aceptar una migración o integración

Nightly Software · Publicado el 5 de octubre de 2026 · Versión 1.0

Estos archivos son **ejemplos sintéticos para evaluar un sistema**, no datos de clientes, resultados medidos ni un importador listo para producción. Los nombres de productos, almacenes, pedidos y operaciones son inventados. Las decisiones son una propuesta de aceptación que tu responsable de operación debe adaptar y aprobar. No subas inventarios, documentos de clientes ni credenciales reales a una herramienta pública para probarlos.

## Archivos

- [Migración de inventario desde Excel](https://nightlysoftware.com/datos/migracion-inventario-ejemplo.csv): ocho casos de catálogo, unidades y saldos.
- [Traspasos entre almacenes](https://nightlysoftware.com/datos/traspasos-almacenes-ejemplo.csv): diez estados de una operación con reserva, bloqueo y recepción parcial.
- [Integración de ERP](https://nightlysoftware.com/datos/integracion-erp-ejemplo.csv): seis casos de confirmación, reintento y autoridad del registro.

Los CSV usan UTF-8, coma como separador y punto para decimales. Impórtalos como texto o indica el separador al abrirlos en tu hoja de cálculo. Conserva SKU e identificadores como texto. Un campo vacío significa **desconocido o no aplicable**, nunca cero. Los campos `decision_esperada` y `accion_esperada` describen el resultado esperado en una demostración; no son instrucciones que un sistema deba ejecutar automáticamente.

## 1. Migrar sin ocultar diferencias

Fórmulas del ejercicio, cuando hay datos aprobados:

`cantidad_base = cantidad_origen × factor_unidad_base`

`diferencia = conteo_fisico_base − cantidad_base`

- **M01:** 120 piezas de TOR-M6, conteo físico de 120: diferencia 0. La coincidencia numérica no sustituye la aprobación del archivo de origen y la fecha de corte.
- **M02:** otra fila se normaliza al mismo SKU TOR-M6 y almacén ALM-A. No sumes 120 + 30 automáticamente: puede ser un duplicado, otra ubicación o un registro de otro momento. Confirma la procedencia y la clave de negocio antes de combinar.
- **M03:** cuatro cajas de ACE-01 equivalen a 48 piezas únicamente si la conversión de 12 piezas por caja está aprobada para ese producto. Tener 48 piezas contadas no prueba por sí solo que la conversión sea correcta.
- **M04:** dos cajas sin factor aprobado. El conteo físico de 24 no autoriza inferir y guardar un factor de 12. Detén la carga de ese registro hasta resolverlo.
- **M05:** un saldo coincide con el conteo, pero no tiene identificador. Detén el registro; un total correcto no hace confiable un catálogo sin claves.
- **M06:** el archivo dice 20 y el conteo 18: diferencia −2. Documenta la causa y la decisión autorizada antes de abrir la operación; no ajustes en silencio.
- **M07:** cero es un saldo válido si el catálogo y el corte están aprobados. No elimines el producto porque no tenga existencia.
- **M08:** −3 litros registrados y 0 contados: diferencia +3. Conserva la evidencia y revisa el origen; no conviertas negativos a cero para que el reporte parezca correcto.

Antes de aceptar el corte, registra archivo/versiones, claves de catálogo y ubicación, responsable del conteo, momento de corte, diferencias y decisión de apertura. Un respaldo sin una prueba de restauración no basta para aprobar el regreso al sistema anterior. El regreso también debe conciliar los movimientos hechos desde el corte: no los borres ni los pierdas al restaurar.

Guía completa: [Migrar inventario de Excel a un sistema](https://nightlysoftware.com/blog/migrar-inventario-de-excel).

## 2. Separar existencia y disponibilidad

Este ejercicio usa piezas de un solo SKU, reservas y bloqueos que no se superponen. Es una convención del ejemplo; acuerda las reglas de tu sistema antes de aplicar las fórmulas.

`disponible_A = existencia_A − reservado_A − bloqueado_A`

`total_controlado = existencia_A + existencia_B + en_transito`

| Caso | A: existencia / disponible | B: existencia | En tránsito | Qué debes observar |
| --- | --- | --- | --- | --- |
| T00 | 100 / 85 | 20 | 0 | 10 reservadas y 5 bloqueadas siguen físicamente en A. |
| T01 | 88 / 73 | 20 | 12 | Se confirma la salida de 12; B todavía no las recibe. |
| T02 | 88 / 73 | 28 | 4 | B confirma 8 recibidas; 4 quedan pendientes. |
| T03 | 88 / 73 | 28 | 4 | Repetir REC-001 no genera otra recepción. |
| T04 | 92 / 77 | 28 | 0 | Las 4 pendientes regresan y A confirma físicamente su recepción. |
| T05 | 92 / 77 | 28 | 0 | Reservar 80 adicionales se rechaza: solo hay 77 disponibles. |
| T06 | 92 / 77 | 28 | 0 | Cancelar no reescribe ni borra las 8 piezas ya recibidas en B. |
| T07 | 92 / 82 | 28 | 0 | Liberar 5 de la reserva original cambia disponibilidad, no existencia. |
| T08 | 92 / 72 | 28 | 0 | Bloquear 10 más cambia disponibilidad, no el total físico. |
| T09 | 92 / 72 | 28 | 0 | Vender 73 se rechaza bajo la regla acordada de no sobreventa. |

El total permanece en 120 en todos los estados. Una cancelación no hace regresar mercancía por sí sola: T04 requiere confirmación física. Si hay pérdida o daño, registra una diferencia o ajuste autorizado, con su evidencia; no fuerces conservación ficticia. Prueba también dos personas intentando reservar la última pieza, recepción mayor a la cantidad pendiente, unidades distintas y un usuario sin permiso para aprobar ajustes. Define si tu política admite pedidos pendientes; no mezcles esa decisión con existencia disponible.

Guía completa: [Inventario entre almacenes](https://nightlysoftware.com/blog/inventario-entre-almacenes).

## 3. Reintentar sin duplicar ni sobrescribir

- **E01:** op-100 para ORD-100 queda confirmado una vez y conserva el identificador del registro de destino.
- **E02:** el segundo intento de op-100 devuelve el resultado previo, sin crear otro pedido. Esta prueba requiere un mecanismo acordado y soportado de deduplicación; un folio escrito en un log no garantiza idempotencia.
- **E03:** hubo timeout para op-200 y no sabes si el destino creó ORD-200. `registros_esperados` queda vacío a propósito. Consulta por una clave soportada y concilia antes de reenviar una creación. Si el proveedor no permite consultar o deduplicar, usa una cola de revisión y una decisión manual; no prometas un reintento seguro automático.
- **E04:** el pedido exige 10 unidades y solo hay 8 recibidas. Las 2 restantes deben conservar su estado pendiente o tener una diferencia autorizada; un código HTTP correcto no equivale a una entrega completa.
- **E05:** permiso denegado: no crees el registro con otra identidad más privilegiada ni amplíes permisos como parte del reintento.
- **E06:** otra persona cambió el registro durante la sincronización. No sobrescribas sin revisar la versión y el sistema autorizado para ese campo.

Antes de aceptar, acuerda quién manda para cada dato, dirección de sincronización, permisos mínimos, disponibilidad de API según contrato/plan, claves de deduplicación, conciliación, bitácora sin secretos, responsables de excepciones y cómo detener el conector. No todos los ERP exponen los mismos recursos ni garantizan la misma política de reintento. Las facturas, timbrado, pagos y obligaciones fiscales necesitan su revisión específica; este ejercicio no acredita cumplimiento ni ejecuta esas operaciones.

Guía completa: [Conectar un ERP sin reemplazarlo](https://nightlysoftware.com/blog/conectar-erp-sin-reemplazarlo).

## Cómo pedir una demostración útil

Entrega únicamente los ejemplos sintéticos y las reglas acordadas. Pide al proveedor ejecutar el caso correcto, su excepción y su reintento; registra resultado observado, evidencia, responsable y decisión. Un caso esperado es una hipótesis hasta que se prueba en el entorno y con la versión que vas a recibir. Estos archivos no certifican ningún producto ni demuestran que Nightly ya haya implementado estas reglas para un cliente.

[Cómo trabajamos y plantilla de alcance](https://nightlysoftware.com/como-trabajamos#plantilla-alcance) · [Diagnóstico gratuito](https://nightlysoftware.com/agendar) · [English instructions](https://nightlysoftware.com/datos/pruebas-operacion-en.md).