# Análisis: ¿migrar COMFAR de XPERT_PRO_COMFAR a XPERT_SAPB1?

Fecha del análisis: 2026-08-03

## Conclusión

**No conviene migrar COMFAR a XPERT_SAPB1 como reemplazo.** XPERT_SAPB1 no es "una versión más completa" de PRO_COMFAR — es un motor WMS genérico distinto, más joven y con una arquitectura más limpia en algunos puntos, pero le falta casi todo lo que hace que PRO_COMFAR funcione específicamente para el negocio real de COMFAR (farma + manufactura + Óptica + compliance regulatorio panameño).

## Origen de ambos proyectos

- **XPERT_PRO_COMFAR**: sistema real en producción, conectado a SAP B1 real del cliente (`200.10.10.151:50000`). ~30.900 líneas PHP en `src/`, backup histórico incorporado a git el 2026-07-23 (el código preexistía como deploy manual), con iteración constante y activa sobre pedidos reales del cliente.
- **XPERT_SAPB1**: fork de XPERT3PL (motor 3PL multi-cliente) al que le sacaron el concepto multi-empresa y le agregaron conexión a SAP B1 vía Service Layer. **175 commits, todos concentrados en 12 días (11 al 23 de julio de 2026)**, con `Co-Authored-By: Claude Sonnet 5` visible en varios commits — desarrollo asistido por IA a alta velocidad. Sus propios autores relevaron explícitamente el código de COMFAR para portar patrones puntuales (slotting, backup, auto-asignación de tareas, agrupación del mapa de depósito). Nunca corrió contra un SAP real ni con un cliente real — todos los datos son demos ficticias (Cimplast, Central Motor, Embal). No tiene tests automatizados. Al menos una entidad SAP (`PurchaseReturnRequests`) tiene el nombre sin confirmar contra SAP real, señalado así en el propio código.

## Lo que COMFAR tiene hoy y XPERT_SAPB1 NO tiene

Cada uno de estos puntos implicaría desarrollo nuevo desde cero, no migración de datos:

1. **Subsistema Óptica completo** (~2.780 líneas: `OpticaController` + `OpticaService` + `OpticaSapService`) — recepción simultánea con FEFO, reordenamiento de bins, fragmentación, agendas propias, picking con ruta, posteo a SAP con datos de transporte (chofer/vehículo/km) para la Nota de Remisión Electrónica panameña. No existe ni una mención de "Óptica" en todo XPERT_SAPB1.
2. **Ruteo obligatorio de productos CONTROLADOS** (`items.u_clase='CONTROLADO'`) hacia zonas exclusivas de picking y storage, con validación bidireccional — no existe en XPERT_SAPB1.
3. **Codificación interna de lote de manufactura** (`LotCodeService`) para materia prima y materiales/empaques, con formato y secuencia propios (mensual/anual) — confirma que COMFAR fabrica, no solo distribuye. XPERT_SAPB1 no tiene ningún concepto de manufactura.
4. **"Sala de pesadas"** (`zone_picks`: picking inter-zona para fraccionamiento/pesada de materia prima) — no existe en XPERT_SAPB1.
5. **Compliance DINAVISA/BPA/GAMP5/21 CFR Part 11** embebido como reglas de negocio: "1 LPN = 1 producto + 1 lote + 1 vencimiento + 1 estado QA", recepción ciega multi-OC, trazabilidad de controlados, auditoría explícitamente alineada a GAMP5/Anexo 11. XPERT_SAPB1 tiene auditoría genérica (técnicamente más robusta: hash encadenado inmutable vía triggers), pero cero de las reglas de negocio regulatorias específicas de farma panameña.
6. **Costing codes SAP por grupo de item y por proveedor** calibrados a la contabilidad real de COMFAR (`EUROFARM`, `RX`, `OTC`, `OTX`, `FABRICA`, `MUESTRAS`, `COMADM`, `BIODERMA`).
7. **Matriz de permisos RF** con historial real de 8 migraciones de ajuste pedidas por el cliente (evidencia de uso activo real, no features de catálogo).
8. Reposición automática de picking con motor propio (`item_picking_levels` + `ReplenishmentService`) — dato que corrige un supuesto previo de que "COMFAR no tenía esto"; sí lo tiene y funciona.

## Lo que XPERT_SAPB1 tiene y es genuinamente mejor

- **Auditoría inmutable con hash encadenado** (trigger `BEFORE UPDATE/DELETE` que aborta + `prev_hash`/`row_hash` sha256) — más robusto que el `audit_log` actual de COMFAR.
- **Módulo ABC/Pareto** y **módulo DRP** (planificación de reposición entre sucursales) — probablemente poco relevante para COMFAR hoy, que opera un solo almacén real (`CENMRA`).
- **Control de acceso por almacén** más granular (`user_warehouses`) — COMFAR ata cada usuario a un único `warehouse_id`, pero al tener un solo almacén real tampoco es una limitación práctica hoy.
- Integración SAP algo más limpia y mejor documentada (`docs/integracion-sistemas-externos.md`, pensada explícitamente para portabilidad a otros ERPs).
- Slotting por categoría (`zone_category_rules`) con diseño más simple, inspirado directamente en el patrón de COMFAR pero con una sola dimensión de categoría en vez de las dos que usa COMFAR (`item_group`/`u_subgrupo`).

**Config de impresoras Zebra es peor en XPERT_SAPB1**: vive en `localStorage` del navegador (ni siquiera server-side), mientras que COMFAR al menos la persiste en `system_config` (aunque sin UI admin todavía en ninguno de los dos).

## Hallazgo de seguridad (independiente de esta decisión)

En `XPERT_PRO_COMFAR/src/config/app.php` hay **credenciales de SAP y HANA hardcodeadas y commiteadas al repo git**. Vale la pena resolverlo aparte de esta decisión — moverlas a variables de entorno.

## Recomendación

No migrar como reemplazo. El camino de menor riesgo es el inverso al que ya venía pasando naturalmente: **backportear ideas puntuales de XPERT_SAPB1 hacia XPERT_PRO_COMFAR** (el hash-chain de auditoría, el control de acceso por almacén si algún día suman un segundo depósito, quizás ABC si les sirve), en vez de reconstruir las ~12 personalizaciones regulatorias y de negocio de COMFAR sobre una base de 12 días de antigüedad que nunca corrió contra un SAP real ni con un cliente real.