Alcance de validacion integral antes de retirar FK

Base del usuario: todos los contribuyentes siguen en pruebas, segun confirmacion.
No existe conexion MySQL configurada en este entorno. Los siguientes escenarios
son pendientes de ejecucion real; no se presentan como pruebas aprobadas.
Conservar un respaldo recuperable antes de modificar el esquema de esa base.

Para cada modulo: ejecutar un flujo valido, editarlo, anularlo y repetirlo; probar
IDs inexistentes/de otra empresa/de otra cabecera, peticiones duplicadas, fallo
durante escritura y dos sesiones concurrentes. Revisar conteos de huerfanos,
sumas de stock, deuda, caja e historial despues de cada prueba.

1. Productos y ubicaciones
   Crear atributo/valor/variante; repetir combinacion; editar valores; padre de
   ubicacion correcto/ajeno; activar variantes; redistribuir stock con reserva.
   No debe perder stock ni aceptar variantes/ubicaciones inexistentes.
2. Inventario
   Crear zonas con/sin ubicacion, iniciar, contar, cerrar/reabrir, aprobar/aplicar.
   Rechazar zona de otro inventario y referencias ajenas; aplicar solo una vez.
3. Pedidos y autorizaciones
   Guardar/editar, solicitar precio y stock, aprobar/rechazar/expirar, llevar a
   caja, emitir/anular. No reactivar ANULADO/ATENDIDO; no crear historiales sin padre.
   Comprobar aprobacion concurrente con edicion y con anulacion.
4. Caja
   Abrir turno, arqueo, movimiento manual/reverso, cobrar, conciliar, cerrar y
   destinar fondos. Probar cierre concurrente con cobranza/conciliacion. Validar
   caja fisica, turno y movimiento; ninguna conformidad debe apuntar a otro turno.
5. QR
   Proveedor/terminal/orden/evento/aplicacion, callback repetido y cancelacion.
   Verificar terminal y turno vigentes en el instante del registro; mantener
   idempotencia y no registrar un cobro por evento invalido.
6. Compras
   Orden, recepcion, documento proveedor, aplicacion, incidencia, resolucion,
   adenda, NC y saldo proveedor. Detalles siempre de la cabecera correcta;
   rechazo o rollback no debe ajustar Kardex, cuentas ni saldos parcialmente.
7. Postventa
   NC/devolucion, saldo, reserva/aplicacion, solicitar/autorizar/ejecutar reembolso.
   No devolver dos veces ni usar una operacion cancelada/de otra empresa.
8. Canjes y reversiones
   Reservar una/multiples notas, confirmar CPE, liberacion/reversion y regularizacion
   fiscal. Comprobar misma empresa/sucursal/moneda/cliente y no duplicar venta,
   stock ni cobranza. Fallo SUNAT no debe dejar referencias operativas rotas.
9. Repartos
   Asignar, iniciar, resultados, retorno/reingreso, rendir/revisar/validar cobranza.
   Entrega/jornada/rendicion/detalle deben coincidir. No repetir abono ni eliminar
   detalles referenciados. Probar reenvio y dos validaciones simultaneas.
10. Traslados
    Preparacion, detalle, viaje/guias, entrega parcial, recepcion, incidencias y
    Kardex de correccion. No ejecutar movimientos con guia/producto/cabecera ausentes.
11. Metas y precios
    Equipo/integrantes, meta padre/hija, snapshot/historial; grupos/ajustes/precios,
    programacion, vigencia y reversion. Validar referencias y pertenencia, incluyendo
    cambios concurrentes en padres e integrantes.

Puntos pendientes de especial atencion detectados en lectura estatica
- Consultas de existencia ejecutadas antes de begin o sin FOR UPDATE: pueden
  quedar obsoletas antes de insertar. Ejemplos: conformidad de conciliacion de caja,
  orden QR, validacion de cantidad acumulada de incidencias, componentes de metas.
- Resolver autorizaciones de stock/precio se reforzo con bloqueos y transacciones;
  aun hay que ensayar anulacion/atencion concurrentes en MySQL real.
- Los siete enlaces sin referencias textuales fuera de modelos requieren comprobar
  SQL dinamico, instalaciones antiguas, integraciones y tareas externas.
- Borrados manuales/TRUNCATE y escritores externos no quedan protegidos por PHP.
  Toda limpieza debe respetar listas explicitas y dependencias logicas.
- Datos sin huerfanos bajo FK no prueban comportamiento del sistema sin FK.

Criterio de salida
No ejecutar el borrador de retirada ni editar migraciones hasta completar la
integracion real, resolver estos puntos y confirmar ausencia de nuevas referencias
rotas despues de flujos, fallos y concurrencia. La revision estatica es soporte,
no una certificacion de que todos los caminos funcionan sin claves foraneas.
