# Migrar un catálogo legado (`Mae*Controller`) a Diccionario Runbook técnico para convertir uno de los ~30 controladores legados `Mae*Controller.php` de `mbinv` (CRUD hecho a mano, uno por tabla) en configuración de Diccionario (metadata-driven, sin código nuevo). Distinto de `DEPLOY.md` (ese es el manual de soporte para desplegar/activar el módulo en un cliente — este es el proceso para migrar una tabla puntual). Todo el trabajo de este runbook se hace contra `mbinvdiccionario` (132.226.40.48:3310, user `manuel`) — la base de pruebas dedicada a curar la plantilla general, nunca contra `mbinvinstalar` real. Ver DEPLOY.md sección 4 para cómo esa configuración llega después a un cliente real. ## 0. Clasificar la tabla antes de empezar No todos los `Mae*Controller` son iguales. Mirar el tamaño del archivo y qué hace, no solo el nombre: - **Clase A — CRUD puro**: código + descripción y poco más, sin lógica de negocio. Migra directo con este runbook, sin sorpresas grandes. - **Clase B — CRUD con 1-3 rasgos especiales**: FK con opción extra fija, "duplicar con siguiente código", subformularios por pestaña, campo con imagen, etc. Migra con este runbook + resolver esos rasgos puntuales (ver sección 6, "Huecos conocidos"). - **Clase C — no es un catálogo real**: motor de reglas, módulo transaccional completo (facturación, pedidos, etc.), o ni siquiera es una tabla maestra a pesar del nombre `Mae*`. **No migrar** — forzarlo al modelo de Diccionario es más trabajo que valor. Ejemplos ya identificados: Maepago (no es catálogo), Maeofe/Maedoc/Maeped/Maecli (motores transaccionales), Maepro/Maeusr/Maeven (necesitan que primero se saque su lógica especial — upload de imagen, sync contable externa, árbol de permisos — a servicios aparte). ## 1. Reunir la información del controlador legado Antes de tocar `dic_campo`, leer estos 4 archivos de `mbinv` (el checkout principal, no el worktree de Diccionario): 1. **`Entity/{Tabla}.php`** — columnas físicas, tipos, y sobre todo la llave primaria: `@ORM\Id` + `@ORM\GeneratedValue(strategy="IDENTITY")` significa auto-incremento real (Diccionario ya lo maneja solo); sin `GeneratedValue`, el código probablemente se autoasigna a mano en `createAction` (ver punto 3). 2. **`Form/{Tabla}Type.php`** — qué campos usa el formulario legado (`->add('campo', ...)`) y sus labels. Ojo con dos trampas (ver sección 5): nombres en camelCase que no calzan con la columna real, y líneas `->add(...)` comentadas que igual "cuentan". 3. **`Repository/{Tabla}Repository.php`** — si existe un método `sePuedeBorrar($pk)`, ahí está la regla de restricción de borrado (normalmente `SELECT COUNT(*) FROM tabla_hija WHERE campo_fk = :pk`). Si no existe el repositorio o el método, el legado no protege el borrado — no inventar una restricción que no estaba. 4. **`Controller/{Tabla}Controller.php`**: - `indexAction`: buscar `$entityId`/`$entityIdLabel` — dice qué columna usa el LISTADO como "código" (a veces es la PK real, a veces es un campo secundario tipo `idemisor`, no lo asumas). - `createAction`: buscar un patrón `SELECT max(e.campo) ... + 1` — es el "código automático", ver sección 4. ## 2. Generar los campos mecánicamente ```php $dic->crearTablaDesdeEsquema('tabla', 'campo_pk_fisico', 'Código'); ``` Esto trae todas las columnas físicas, detecta cuáles usa el `Type.php` legado (oculta las que no), y documenta títulos desde los labels que encuentre. Es re-ejecutable sin pisar ediciones humanas — no tiene problema correrlo de nuevo si hace falta ajustar algo. Si la tabla no existía antes en `dic_tabla`, agregar el título/descripción: ```php INSERT INTO dic_tabla (tabla, titulo, descripcion, orden) VALUES ('tabla', 'Título Plural', 'Descripción corta para el usuario.', 0); ``` ## 3. Revisar y corregir lo que el auto-detector no puede saber **Siempre revisar el resultado antes de darlo por bueno** — el auto-detector es un parser de regex simple sobre el `Type.php`, tiene límites conocidos (ver sección 5). Con la tabla ya creada, comparar `SELECT campo, titulo, visible_lista, visible_form FROM dic_campo WHERE tabla=?` contra el `Type.php` leído en el paso 1, campo por campo. ## 4. Código automático (patrón "MAX + 1") Muy común en los catálogos viejos: el código no lo escribe el usuario, se autoasigna en el servidor (`SELECT MAX(campo)+1`) y ni aparece en el formulario. Diccionario tiene un token para esto — `Dic::AUTO_SIGUIENTE` (`{auto_siguiente}`) en `valor_default` — que `createFila()` resuelve siempre en el servidor, nunca confía en lo que mande el cliente. Dos variantes, según cómo se comporte en el legado: - **Nunca se muestra** (ni al crear ni al editar) — caso típico de la PK natural (ej. `maedep.depto`, `maeuni.unidad`): ```php UPDATE dic_campo SET valor_default='{auto_siguiente}', visible_form=1 WHERE tabla=? AND campo=?; -- visible_form=1 es necesario (el ocultado-en-creacion es un check aparte -- en el frontend), pero si el legado tampoco lo muestra en EDICION, -- hay que además ponerlo en 0 para ocultarlo del todo: UPDATE dic_campo SET visible_form=0 WHERE tabla=? AND campo=?; ``` - **Se muestra siempre pero deshabilitado** (ej. `maemex.codigo`, con `'disabled' => true` en el Type.php) — se autoasigna igual, pero además debe verse (de solo lectura) al editar: ```php UPDATE dic_campo SET valor_default='{auto_siguiente}', visible_form=1, solo_lectura=1 WHERE tabla=? AND campo=?; ``` El token funciona en **cualquier columna**, no solo en la PK — ej. `maeemi.idemisor` es un contador aparte de la PK real (`id`, autoincremento de verdad) y usa el mismo mecanismo. ## 5. Trampas conocidas del auto-detector (`crearTablaDesdeEsquema`) Encontradas migrando las 11 tablas de la ola A — revisar siempre, no asumir que el resultado automático está completo: 1. **No entiende comentarios PHP.** Un `//->add('campo', ...)` comentado en el legado igual matchea la regex y se marca como "usado" (visible). Encontrado en Maeemi (`imprimedetalle`) y Maeuni (`contenido`, `caja`). Si un campo quedó visible pero en el `Type.php` está comentado, ocultarlo a mano. 2. **No mapea camelCase↔snake_case.** El regex busca el nombre de propiedad PHP (`->add('voucherEncabezado', ...)`), pero `crearTablaDesdeEsquema` compara contra el nombre de columna física (`voucher_encabezado`) — nunca hacen match, así que el campo queda oculto por error. Encontrado en 15 de los 27 campos de Maeemi, y de nuevo en Maepro (`caftaNombre`, `pedidoWebSite`, `contactoEmail`, `tipoProveedor`, `pedidoFormato` — 8 campos). Revisar especialmente en tablas con muchos campos `snake_case` con nombre de propiedad `camelCase` distinto. Cuando alguno de estos dos casos aparezca, corregir con: ```php UPDATE dic_campo SET visible_lista=1, visible_form=1, titulo='...' WHERE tabla=? AND campo=?; -- mostrar UPDATE dic_campo SET visible_lista=0, visible_form=0 WHERE tabla=? AND campo=?; -- ocultar ``` ## 6. Features de Diccionario disponibles para campos especiales | Necesidad en el legado | Cómo configurarlo en `dic_campo` | |---|---| | Sí/No con valores `S`/`N` | `val_tipo='si_no'` (atajo, no hace falta `val_valores`) | | Sí/No u otro choice con otros valores (ej. `0`/`1`) | `val_tipo='lista_valores'`, `val_valores` en JSON `[{"value":"0","label":"No"},...]` | | Lista de valores fija con más de 2 opciones | igual que arriba, cualquier cantidad de opciones | | FK a otra tabla (select con etiqueta resuelta) | `rel_tipo='fk'`, `rel_tabla`, `rel_campo` (columna PK de la tabla relacionada), `rel_campo_desc` (columna descriptiva) — **el auto-detector nunca infiere esto solo**, siempre a mano | | Campo calculado como copia de otro | `calc_tipo='copia'`, `calc_expr='campo_origen'` | | Multi-select con un valor default (tabla detalle) | `rel_tipo='detalle_multiple'` + `det_tabla_valores`/`det_campo_valor`/`det_campo_valor_desc` — ver panel admin, sección "Detalle múltiple" | | Código automático (MAX+1) | ver sección 4 | | Restricción de borrado (hijos dependientes) | fila en `dic_restriccion` (`tabla`, `campo_pk`, `tabla_hija`, `campo_fk`, `mensaje`) — replicar exactamente lo que decía `sePuedeBorrar()` | ## Huecos conocidos Encontrados en el análisis inicial de las ~14 tablas de clase B. Los 3 primeros ya están construidos (julio 2026) — quedan documentados aquí como referencia de uso, no como pendiente: 1. **FK con opción extra fija o unión de tablas** — ✅ construido. `dic_campo.rel_extra_valor`/`rel_extra_texto` inyecta una opción fija al inicio de la lista (ej. Maecaj → `0 = 'TODAS'` sobre el FK a `maetie`). `rel_tabla2`/`rel_campo2`/`rel_campo_desc2` arma la lista como UNION con una segunda tabla (ej. Maerutas: `maeven` UNION `maecaj`). Se configuran en el panel admin, sección "Tabla rel.", bloque "FK — opción extra / unión con otra tabla". 2. **Acción genérica "duplicar fila con siguiente código libre"** — ✅ construido. `Dic::duplicarFila()` + `POST /dic/datos/{tabla}/{id}/duplicar`. No requiere cambios de frontend — se activa agregando una fila en `dic_accion` con `tipo='proceso'` y `url_patron='{apiBase}/dic/datos/{tabla}/{pk}/duplicar'` (mismo dispatcher `ejecutarAccion` que ya usa cualquier acción tipo `proceso`). Recalcula automáticamente cualquier campo `{auto_siguiente}`; nunca copia columnas marcadas `es_pk=1`. 3. **Grupos de campos en pestañas dentro del mismo formulario** — ✅ construido. `dic_campo.grupo` (texto libre, default null = "General"). Con 2+ grupos distintos entre los campos visibles del formulario, `FormModal.tsx` muestra pestañas automáticamente; si al validar hay un error en un grupo no activo, salta a esa pestaña. Se configura en el panel admin junto al campo "Orden". 4. **Subida de imagen → columna con la ruta** — ✅ construido (julio 2026, a raíz de Maepro). `dic_campo.control_edicion='imagen'` + `dic_campo.imagen_carpeta` (subcarpeta bajo `web/public/images/dic/`). `Dic::guardarImagen()` valida el archivo por contenido real (`getimagesize()`, nunca por la extensión que mande el cliente), tope 5MB, nombre determinístico `{pk}.{ext}` (reemplaza en vez de acumular). No pasa por `createFila()`/`updateFila()` — llega como multipart a `POST /dic/datos/{tabla}/{id}/imagen/{campo}`, endpoint aparte. Frontend (`ImagenInput` en `FormModal.tsx`) sube apenas se elige el archivo, sin esperar al botón Guardar — necesita la PK ya asignada, así que en creación queda deshabilitado con una nota. Caso real: Maepro (`pedido_logo_url`, carpeta `proveedor`). 5. **Campo de contraseña con hash al guardar** — ✅ construido (julio 2026, a raíz de Maecaj). `dic_campo.control_edicion='password'` + `dic_campo.password_hash` (estrategia configurable por campo — hoy solo `md5_upper`, el patrón legado de `maecaj.clave`/`maeusr.clave`; agregar más casos en el `switch` de `Dic::aplicarHashPassword()` si aparece otro, ej. bcrypt). Reglas: vacío al guardar = "no cambiar" (nunca se hashea `''`), y `Dic::getDatos()` **nunca** devuelve el hash real al frontend — el campo siempre llega como `''`, tanto en la grilla como al precargar el formulario de edición. El frontend (`FormModal.tsx`) agrega un segundo input "Confirmar" que es puramente del navegador (no se guarda) y avisa si no coincide antes de guardar. Configurar `obligatorio=0` en este tipo de campo — si no, el formulario exige reescribir la clave en cada edición aunque no se quiera cambiar. Si el legado restringe el formato de la clave (ej. `maecaj.clave`: `ctype_digit()`, solo dígitos — por compatibilidad con algo que la consume, no se investigó qué exactamente), replicarlo con `val_tipo='solo_numeros'` (u otro `validacion_tipo` existente) — la validación del catálogo ya lo revisa solo, sin cambios de motor. ## 7. Verificación end-to-end (obligatoria antes de dar por migrada una tabla) No alcanza con mirar `dic_campo` — probar de verdad: 1. `Dic::getDefinicion('tabla')` y comparar campos visibles contra el `Type.php` legado, uno por uno. 2. `Dic::createFila('tabla', [...], ...)` **sin mandar** los campos con `{auto_siguiente}` — confirmar que el valor se autoasigna y coincide con `MAX(campo)+1`. Repetir la creación una segunda vez para confirmar que sigue incrementando. 3. Si hay `dic_restriccion`: `Dic::deleteFilas()` contra un registro que sí tenga hijos dependientes — debe bloquear con el mensaje configurado. Contra uno sin hijos — debe borrar sin problema. 4. Limpiar cualquier fila de prueba creada durante la verificación. 5. **Visual**: abrir la tabla en `mbinv-catalogo` (local:3000 o qa-manuel), revisar que la lista y el formulario de alta se vean bien — sobre todo en tablas con muchos campos `select`/Sí-No, que son las que más fácil quedan mal configuradas sin que un test de backend lo note. ## 8. Permisos — no olvidar Desde el fix de permisos (julio 2026), **una tabla sin fila en `dic_permiso` para un usuario queda completamente bloqueada para ese usuario** (ver/crear/editar/eliminar) — ya no hay acceso total por default. Toda tabla recién migrada necesita su fila de permiso explícita para el usuario que la va a probar/usar, si no da 403 en todo: ```php INSERT INTO dic_permiso (tabla, user_id, puede_ver, puede_crear, puede_editar, puede_eliminar) VALUES ('tabla', 'usuario_id', 1, 1, 1, 1); ``` ## Ola A — estado (referencia) Las 11 tablas de clase A ya están migradas y verificadas: Maeart, Maecas, Maedep, Maeest, Maemar, Maelin, Maevar, Maemov (comparten plantilla `Entity/*.html.twig` en el legado), y Maeemi, Maemex, Maeuni (vistas propias). Todas con permiso otorgado al usuario de pruebas (`mb`, `user_id=1`). ## Ola B — estado (referencia) **11 de 11 migradas y verificadas — ola B completa**: Maeprocedencia, Maeindustria, Maecocinero (tabla física `maecocineros`), Maemotorista, Maerecipiente, Maetam, Maecup, Maerutas, Maecaj, Maetie, Maetdc. Notas puntuales de esta tanda: - **Maecup** es la más rica migrada hasta ahora (46 columnas físicas, 21 visibles) — tiene una **tercera trampa del auto-detector**, además de las dos ya documentadas en la sección 5: campos con `'mapped' => false` + `style: display:none` en el `Type.php` legado (visualmente ocultos y ni siquiera se guardan) igual matchean la regex y quedan marcados "usados". 14 campos de Maecup cayeron en esto — revisarlos a mano. - **Maerutas**: el legado elige el origen del `choice` de vendedor en tiempo de ejecución (`maeven` si tiene filas, si no `maecaj`) — Diccionario no soporta "FK condicional según datos". Se simplificó a FK fijo → `maeven` (el caso normal). Si un cliente no tiene vendedores cargados, el select queda vacío en vez de caer a `maecaj` — limitación conocida, no bloqueante. - **Maecocineros/Maerutas** tienen un campo tipo `fechabaja` que el legado calcula solo a partir de otro campo (`activo`/`baja`) al guardar — no hay forma de replicar esa lógica hoy en Diccionario (ver huecos abajo), así que se dejó de solo lectura/informativo en la lista, no editable. **Maetdc (Tipos de Documento) — migrada** (julio 2026), reevaluación del diagnóstico anterior. Se creía bloqueada por `getTiposAction()` (cascada de reglas de negocio sobre 6+ banderas de `maemov`), pero al leer el código con más detenimiento: **esa cascada solo alimenta un `` del legado no tiene `multiple` — es un FK simple a `maeven.vendedor`, no `detalle_multiple`. Confirmado también por los datos reales (cero filas con coma). Configurado con opción extra `0 = Ninguno`. - **`tienda`** FK a `maetie.tienda`, opción extra `0 = TODAS` (igual que Maecli/Maecas) — la pantalla legada dedicada `/maecaj/tienda/{id}` para cambiar solo la tienda ya no hace falta: el campo vive en la pestaña "General" del formulario unificado. - **`permite_modificar_cliente_listas`** y **`hace_descuento_lista_listas`** sí son multi-valor real (`` planos sin agrupar (Usar/Desbloquear/Reportar) metidos en el formulario gigante de edición, más una página aparte para el árbol de menú. **Modelo de datos real** (5 dimensiones de permisos por usuario, más grande de lo que parecía al inicio): 1. **Identidad + ~30 flags** — columnas directas en `maeusr` (¿modifica costo?, ¿ve precio?, pedidos a proveedor, traslados, manifiestos, inventario, backorder...). Campo exacto: ver `MaeusrType.php`. 2. **Menú** — árbol de navegación, JSON crudo en `maeusr.menu` (formato plano `[{id,titulo,permitido}]`, armado y aplanado en el navegador — igual en la pantalla legada `accesos.html.twig` como en el panel nuevo). Fuente del árbol: `Parametros::getMenuAll($usuarioId)` (8 categorías top-level, cada una con métodos PHP propios `getMenuCatalogos()`/`getMenuMovimientos()`/etc — no hay tabla `menu` real detrás, esa tabla física es vestigial). 3. **Documentos** — `maetdc` × `dettdc`, 2 flags independientes por tipo de documento (`utilizar`, `desbloquear`). 4. **Tiendas** — `maetie` × `dettie` (la tabla que se investigó al migrar Maetie; confirmado acá que su propósito real es "qué tiendas puede usar cada usuario", no un registro de auditoría). 5. **Reportes** — `web_reporte` (446 filas, solo 52 con `activo='S'`, agrupadas por columna `grupo`: Ventas/Administrativos/CxC/Interfaces/ Inventario) × `web_reporte_detalle` (`activo` char 'S'/'N', no 0/1 como `dettdc`). **Decisión de alcance (usuario, julio 2026)**: construir por fases, empezando por General + Menú + Documentos (las 3 más usadas a diario), luego Tiendas + Reportes en una segunda pasada (Fase 2). **Qué se construyó (Fase 1)**: - Backend: `MaeusrController` — endpoints JSON nuevos bajo `/usuario/api/...` (lista, general get/save/create, menú get/save, documentos get + toggle instantáneo por checkbox). Todo a mano — `getConexion()->fetchAll/fetchOne/executeNonQueryWithParameters` con SQL directo, no Doctrine QueryBuilder ni `Dic::`. Requirió excepción de firewall (`^/usuario/api`, `security.yml`) — mismo patrón que ya existía para `/maecli/api` y `/tienda/api/gface-autocompletar`. - El árbol de Menú reutiliza `Parametros::getMenuAll()` tal cual (no se reimplementó la lógica de los 8 métodos `getMenu*()`) — el endpoint nuevo solo lo expone como JSON en vez de renderizarlo en Twig, y el guardado reusa el mismo `$entity->setMenu(json_encode(...))` que ya usaba `accesosAction`. - Frontend: pantalla nueva `mbinv-catalogo/src/app/usuarios` — **a propósito NO reutiliza `CatalogoGrid`** (aclaración del usuario: la tabla de navegación es chica y concreta, no se beneficia de paginación/export/columnas configurables de un catálogo). Lista simple con búsqueda + 3 pestañas (General/Menú/Documentos), todo en una sola pantalla sin navegar — el árbol de Menú marca/desmarca todo un subárbol al tocar un padre (replica el plugin `checktree` de la pantalla legada). - `usuariosApi.ts` tiene su **propio** `apiFetch` local, no importa el de `api.ts` — ese archivo tiene cambios sin commitear de Pedidos a Proveedor en este repo (ver aislamiento de `api.ts` en las notas de sesión), depender de un export suyo rompía el build en un checkout limpio del servidor (encontrado al desplegar, corregido enseguida). **Qué se construyó (Fase 2 — Tiendas y Reportes)**: - Backend: 4 endpoints nuevos en `MaeusrController`, mismo patrón bespoke de Fase 1 (auth+CORS vía `BaseController`, SQL directo vía `getConexion()`): `GET/POST /usuario/api/{id}/tiendas` y `/tienda` (toggle sobre `dettie`), `GET/POST /usuario/api/{id}/reportes` y `/reporte` (toggle sobre `web_reporte_detalle`, cuidado con `activo` siendo char 'S'/'N' y no 0/1 como en `dettdc`). - Frontend: `TiendasTab.tsx` (lista simple, guardado instantáneo por checkbox, mismo patrón que `DocumentosTab`) y `ReportesTab.tsx` (agrupado por `grupo` con el mismo sistema de tarjetas por color (`ACENTO_GRUPO`) que `GeneralTab`, más buscador — 52 reportes activos sin agrupar habría sido una lista plana interminable). - Verificado end-to-end con datos reales tanto en local (`mbinv-dic`/`mbinv-catalogo` local) como contra el despliegue real (`qa-manuel.sistemasmb.com` + `catalogo.sistemasmb.com`): round-trip de toggle en ambas pestañas, confirmado que el checkbox se deshabilita mientras guarda (`disabled={guardando === id}`) — evita doble-submit, pero hay que esperar a que se rehabilite antes de un segundo click en pruebas automatizadas contra el servidor local (que puede tardar) o el click se pierde silenciosamente (no es bug, es el lock funcionando). **Qué se construyó (Fase 3 — Duplicar usuario)**: - Backend: `apiDuplicateAction` (`POST /usuario/api/{id}/duplicate`, body `{nombre}`). En vez de mantener una lista explícita de columnas (como `MAEUSR_FLAGS`), usa `SHOW COLUMNS FROM maeusr` menos `usuario`/`nombre` y arma un `INSERT ... SELECT` — copia **todo** lo demás de la fila origen (incluida `clave` y `menu`), igual alcance que el clon de Doctrine del `duplicateAction` legado pero sin quedar desactualizado si se agrega una columna nueva a `maeusr`. Reutiliza la misma validación de nombre disponible que `apiCreateAction` (`puede_crear`), y copia también `dettie`/`dettdc`/ `web_reporte_detalle` con `INSERT ... SELECT ... WHERE usuario = origen`. - Frontend: botón "Duplicar…" junto a las pestañas (visible con un usuario seleccionado) → modal que pide el nombre del usuario nuevo (mismo combo de disponibles que "Nuevo usuario") → al terminar, refresca la lista y selecciona automáticamente el usuario recién creado. - Verificado end-to-end (backend por curl y UI por Playwright) contra `mbinvdiccionario` local con un login de prueba desechable insertado y eliminado en `user`+`maeusr`+`dettie`+`dettdc`+`web_reporte_detalle` — confirmado que las 5 dimensiones se copian igual que en el origen. **Fase 3 completa — no queda ningún pendiente explícito para Maeusr.** ## Maeplu (Productos) — el catálogo más grande y complejo, migración por fases **No es una migración estándar de este runbook.** `maeplu` es la tabla que se dejó deliberadamente para el final ("maeplu/maeofe/listaprecios que tienen más complejidad"). El plan completo (auditoría BO vs. legado VB6, hallazgos, arquitectura híbrida recomendada, hoja de ruta de 7 fases) vive en el plan mode file — resumen aquí de lo ya construido. **Hallazgo clave de la auditoría**: 7 subsistemas de maeplu no encajan en el patrón "una fila, campos simples" (fórmulas/BOM, `detuni` con cascada de costeo, imágenes con dos generaciones, listas de precio con 6 variantes de cálculo, mín/máx y localidades con auto-seed por tienda, categorías en árbol N:M, código de barras multi-valor). Por eso el enfoque es **híbrido**: Fase 1 (campos simples) por Diccionario estándar, el resto en paneles bespoke por fase, mismo espíritu que Maeusr. Auditoría del lado legado reveló que `frmExpress.frm` (VB6) **no tiene campos hardcodeados** — es un motor de grilla genérico cuyo set de columnas se arma en runtime desde `maegrd`/`detgrd` (`FUNCION='PRODUCTOS'`, 131 columnas registradas, la mayoría ocultas por defecto, configurable por usuario). No es replicable ni deseable tal cual en un formulario web moderno — el equivalente ya es AG Grid con columnas configurables. **Fase 1 completa (2026-07-18) — campos simples (~49 de 139 columnas físicas)**, sobre un scaffold parcial que ya existía en `dic_campo` de una pasada de auto-detección anterior sin curar (encontrado con bugs: 3 dimensiones con `rel_tabla` configurado pero `control_edicion='text'` en vez de select, 4 dimensiones sin ninguna relación, `fraccion` sin `si_no`, y varios campos derivados/legacy quedaron visibles del auto-detector sin que nadie los hubiera revisado). **2 capacidades nuevas de motor construidas para esto, genéricas — no específicas de Maeplu**: 1. **`control_edicion='autocomplete'`** — ya estaba reservado en `CampoDict`/el `` plano. Conclusión: no hacía falta construir ninguna UI de árbol, la relación N:M (`categorias_detalle`) cabía en el mecanismo genérico `rel_tipo=detalle_multiple` que ya existía — pero al intentar usarlo aparecieron **3 bugs latentes en el motor**, nunca antes disparados porque ningún `detalle_multiple` previo tenía estas características: 1. **Nombre de columna distinto entre maestro y detalle**: el mecanismo asumía que la PK de la tabla de opciones (`det_tabla_valores`) se llama igual que la columna de valor en la tabla detalle (`rel_tabla`) — cierto por coincidencia en `detpro.proveedor`/`maepro.proveedor`, falso en `categorias_detalle.categoria_id` vs. `categorias.id`. Fix: nueva columna `dic_campo.det_campo_valor_maestro` (fallback a `det_campo_valor` si es NULL, no rompe nada existente) usada en 3 sitios de `Dic.php` (`getDefinicion()`, `tablaLookupCampo()`, `getDetalleMultiple()`). 2. **Sincronización con columna simple inexistente**: `getDetalleMultiple()`/ `guardarDetalleMultiple()` intentaban leer/escribir sin condición una "versión simple" del campo directo en la tabla padre — asumía que todo `detalle_multiple` viene de aplanar una columna legacy. `maeplu.categorias` es puramente virtual (nunca existió como columna simple) → `SQLSTATE[42S22]: Column not found`. Fix: ambas funciones ahora chequean `in_array($campo, $this->getCamposValidos($tabla))` antes de tocar la tabla padre. 3. **`categorias_detalle` sin columna `es_default`** (la requiere el mecanismo, ya la tenían `detplu`/`detpro`) — agregada de forma idempotente en `Instalacion.php`, mismo patrón que las otras dos. Los 3 fixes son genéricos — benefician cualquier futuro campo `detalle_multiple` con las mismas características, no solo Categorías. Reutiliza el componente `DetalleMultipleModal.tsx` ya existente sin modificarlo. **Localidades** (tienda × local → fila `detloc`) — bespoke, no encaja en `detalle_multiple` (es una dimensión más: no es "N valores por fila padre" sino "N valores por fila padre × tienda"). Backend `apiLocalidadesGetAction`/`apiLocalidadAgregarAction`/ `apiLocalidadEliminarAction`/`apiLocalidadNuevaAction` en `ProductoController.php`, replicando la validación exacta del legado: duplicado (tienda+plu+local), longitud máxima de `maeloc.local`, unidad heredada de `Producto::getUnidadBase()`, y exclusión UX de localidades ya usadas por el producto en cualquier tienda (no es constraint de BD, es filtro de la lista "disponibles"). Página `app/producto-localidades/[plu]/page.tsx`. **Mín/Máx** (`maeexi`, una fila por tienda) — bespoke, mismo patrón de "auto-seed perezoso" que ya se usó para otras piezas: al primer GET se crea una fila `existmin=0/existmax=0` por cada `maetie` que aún no tenga una, replicando el comportamiento del legado (el seed no ocurre al crear el producto, ocurre al primer acceso a la pestaña). `apiMinMaxGetAction`/`apiMinMaxSaveAction`, guardado validado "todo o nada" (si cualquier fila tiene mínimo > máximo se rechaza el lote completo, no se guarda parcial) — igual que `bulkMinMaxAction` del legado. Página `app/producto-minmax/[plu]/page.tsx`. **Ambas nuevas pantallas usan el mismo mecanismo `dic_accion.tipo='modal'`** descubierto en Fase 2 — ya son 3 paneles bespoke usando este patrón (Valores, Localidades, Mín/Máx), consolidándolo como la forma estándar de embeber pantallas fuera del editor genérico dentro del catálogo. **Verificado end-to-end**: curl contra `mbinvdiccionario` local y `qa-manuel.sistemasmb.com` (ambos endpoints, GET/POST/DELETE) y Playwright contra el despliegue real (`catalogo.sistemasmb.com`) — los 3 botones de acción abren su modal correspondiente, cargan datos reales del PLU de prueba y los formularios coinciden con el diseño esperado. Config exportada a `mbinvestructura` (141 campos, 3 acciones: Valores/ Localidades/Mín-Máx). **Fase 4 completa (2026-07-18) — Imágenes**. Decisión confirmada con el usuario: la generación BLOB (`fotos`/`fotos_detalle`) es la definitiva — la columna legada `maeplu.imagenes` (archivo en disco, con marca de agua) no se porta, 0 filas la usan en producción. **Estructura real** (confirmada contra la BD, no solo el código): portada = `fotos` (1:1 vía `UNIQUE KEY plu`, no hay columna `es_principal`, la unicidad de la fila ES la marca de portada). Galería = `fotos_detalle` (N:1, ordenada por `correlativo`) — sin entidad Doctrine, todo por SQL crudo; 0 filas en producción al momento de migrar (sin datos legados de galería que preservar). **Cómo se sirve**: el legado nunca sirve el BLOB por HTTP — lo materializa a `web/public/images/botones/producto_{plu}.jpg` en el primer GET (caché de filesystem sin invalidación por TTL, dos copias del mismo código en `viewAction`/`imagenAction`) y deja que el webserver sirva el archivo estático. El panel nuevo no reinventa ese caché: sirve el BLOB como **data URI base64 embebido en el JSON** (mismo patrón que `Reportes/ProductosConFoto.php`, que ya hace `TO_BASE64()` en SQL), con el mime real detectado por contenido (`getimagesizefromstring()`) en vez de asumir siempre JPEG como hace todo el código legado. El caché de disco legado se invalida (`unlink`) cada vez que este panel cambia la portada, para que las vistas viejas (`view.html.twig`, `imagenAction`) no sigan sirviendo una imagen vieja. **Backend** (`ProductoController.php`): `apiFotosGetAction` (GET), `apiFotoPrincipalSaveAction`/`apiFotoGaleriaSaveAction` (POST), `apiFotoGaleriaEliminarAction` (DELETE) y `apiFotoGaleriaUsarComoPrincipalAction` (POST) — esta última es **funcionalidad nueva, no existía en el legado**: promueve una foto de galería a portada intercambiando con la portada actual (que pasa al final de la galería en vez de perderse), a diferencia del intercambio puramente visual sin persistir que tenía el template legado (`imagen.html.twig`, clic en miniatura no guardaba nada). Portada se guarda por upsert Doctrine (mismo patrón que `fileAction` del legado, aprovecha el `UNIQUE KEY plu`); galería reutiliza `Conexion::saveGaleryImage()` ya existente (bind de blob correcto con `PDO::PARAM_LOB`) en vez de reimplementar ese binding a mano. Cada cambio de portada sincroniza `maeplu.foto` ('S'/'N', antes solo se actualizaba de forma perezosa al visitar la ficha vieja) para no desactualizar los reportes "Productos con/sin Foto". **Bug corregido de paso**: `eliminarFotoAction` del legado no parametrizaba `$plu` en el `DELETE`/`UPDATE` de reordenamiento de `fotos_detalle` (`WHERE plu = $plu` sin comillas) — se rompía con PLUs no puramente numéricos. El endpoint nuevo usa `executeNonQueryWithParameters` en ambas queries. **Límites nuevos** (no existían en el código legado, que no validaba nada de esto — auditoría explícita, sin GD/Imagick en ningún punto del flujo legado): máx. 5 MB por imagen, formatos JPEG/PNG/WEBP validados por contenido real vía `getimagesizefromstring()` (no por extensión ni MIME del navegador), máx. 12 fotos en galería. Sin redimensionado ni generación de miniaturas server-side (tampoco existía antes). **Verificado end-to-end**: curl contra `mbinvdiccionario` local (los 5 endpoints, incluyendo verificación byte-a-byte del intercambio portada↔galería decodificando el primer píxel de cada PNG de prueba para confirmar que los colores correctos terminan en el lugar correcto) y Playwright tanto local como contra el despliegue real (`qa-manuel.sistemasmb.com`+`catalogo.sistemasmb.com`): subir imagen principal, subir a galería, promover una foto de galería a portada (con la anterior reapareciendo al final de la galería), eliminar de galería con recompactación de correlativos, y rechazo de formato no soportado. Datos de prueba limpiados tras verificar. Config exportada a `mbinvestructura` (141 campos, 4 acciones). **Fase 5 completa (2026-07-18) — Listas de precio**, con un alcance reducido a propósito (confirmado con el usuario) tras descubrir en auditoría que el sistema real tiene **4 subsistemas**, no 2 como decía el plan original: maestro `listaprecios` (35 columnas), detalle `listapreciosdetalle` (precio calculado por producto×lista), `listaprecios_criterios` (motor de aplicación masiva por SQL dinámico, depende de `maegrd` — el mismo motor de grilla configurable ya descartado para Maeplu) y `listapreciosmayoreo` (precios por volumen, CRUD propio sin cascada de cálculo). Esta fase cubrió los primeros dos; los otros dos quedan fuera de alcance por ahora. **Maestro `listaprecios`**: migrado como catálogo genérico normal de Diccionario (15 campos curados de 35 físicos, siguiendo exactamente el formulario que ya usa el CRUD legado `Listaprecios/index.html.twig` — los ~20 campos restantes ni siquiera están expuestos ahí, quedaron sin `dic_campo`). Encajó sin fricción: el único caso "especial" — solo una lista puede ser la estándar (`estandar='S'`) — usa `dic_campo.valor_unico` tal cual, la misma capacidad de motor construida en la ola de Maetie, sin tocar nada nuevo. Acción "Duplicar" agregada con el patrón estándar ya usado en otros catálogos. `tiendas` (CSV de códigos de tienda en el legado, con sentinela `0`=todas) se dejó como campo de texto simple en vez de construir un multi-select nuevo — simplificación deliberada, documentada aquí por si algún cliente real lo necesita más completo. **Detalle por producto (`listapreciosdetalle`)**: bespoke, mismo `dic_accion.tipo='modal'` que las fases anteriores. Backend (`apiListasGetAction`/`apiListasSaveAction`) **no reimplementa nada del cálculo** — llama directo a `Producto::setPreciosTodasLasListas()` (para forzar el recálculo al abrir, igual que `listaPreciosAction` del legado) y `Producto::setPrecioLista()` (para guardar, sea por margen o por precio). El switch de las 6 variantes de `costo_para_calculo` (Mejor, Bajo, Actual, Promedio, Último, Móvil) vive únicamente en `Producto.php` — el endpoint nuevo solo lee su resultado. **Hallazgo de inconsistencia real, resuelto por decisión del usuario**: para listas con `margen_tipo='C'`, el endpoint legado (`ProductoController::listaPreciosIdAction()`, ruta vieja `/listapreciosid/{id}`) tenía una fórmula distinta e incluso más incompleta que `Producto::setPrecioLista()` — ni siquiera usaba el costo en el cálculo final del precio, solo el precio estándar del producto. El usuario confirmó usar la fórmula de `Producto.php` (`margen=(precio_lista−costo)/costo×100`, `precio=costo×(1+margen/100)`) como la correcta; el endpoint nuevo la hereda automáticamente al llamar a `setPrecioLista()` en vez de reimplementar, así que el bug legado no se propaga. **Límite conocido, no resuelto** (documentado, no corregido en esta fase): el legado VB6 (`frmListaPrecios.frm`) valida que el precio de lista no pueda quedar por debajo del costo; ni el BO actual ni este endpoint nuevo replican esa validación — el costo relevante depende de cuál de las 6 variantes tenga configurada la lista, calculado dentro de un método privado de `Producto.php` que habría que exponer para validar sin reimplementar el cálculo. **Verificado end-to-end**: curl contra `mbinvdiccionario` local y `qa-manuel.sistemasmb.com` (crear lista no-estándar, forzar recálculo, guardar por margen y por precio, confirmando aritméticamente que el costo usado es el correcto — `sicosto×(1+iva/100)` para la variante "Mejor Costo" — y que ambas direcciones del cálculo bidireccional dan resultados consistentes) y Playwright contra el despliegue real (`catalogo.sistemasmb.com`): el botón "Listas" abre el modal, la tabla carga la lista de prueba, guardar por margen actualiza el precio correctamente. Datos de prueba limpiados tras verificar. Config exportada a `mbinvestructura` para ambas tablas (`maeplu`: 141 campos/5 acciones; `listaprecios`: 15 campos/1 acción). **Fase 6 completa (2026-07-20) — "Copiar de otro producto"**, fuera del orden original del plan (el usuario pidió priorizarla sobre Fórmulas/ Producción). Antes de construirla se auditó "Ofertas" (`maeofe`) como posible Fase 6 alternativa — el usuario decidió **no tocar Ofertas por ahora** ("está en pruebas [en otro lado]"), así que queda sin fase asignada, ver hallazgos completos más abajo. **Hallazgo clave, corrige una premisa del usuario**: se pensaba que el mecanismo real de "copiar producto" usaba `maegrd.copiar_al_duplicar` como bandera por campo. Investigación exhaustiva (grep en todo el código PHP y VB6, `git log -S` sobre ~9200 commits de todas las ramas) confirmó que esa columna **nunca fue conectada a ningún código** — está huérfana en el esquema, todo en `'N'`/`'U'` sin lector real. El mecanismo que sí funciona hoy es un allowlist de ~35 campos **hardcodeado en JavaScript** dentro de `Producto/add.html.twig` (botón "Copia de Código", solo en alta de producto, líneas 168-254 del handler): el usuario solo teclea el PLU origen en un modal, sin ver ni elegir qué se copia — el JS rellena siempre los mismos campos del formulario, dejando el PLU (siguiente disponible) y el código de barras (`label`, se limpia explícito) fuera. **Diseño nuevo**: `dic_campo.permite_copiar` (columna nueva del motor genérico, no específica de Maeplu) marca qué campos son elegibles — esta vez sí real y administrable desde el editor de campos del admin de Diccionario (checkbox "Permite copiar", mismo patrón que "Sufijo al duplicar"). Sembrado inicial: 46 campos simples de `maeplu` (General, Atributos, Comandas, Contabilidad, Tablas —las 9 dimensiones—, Trazabilidad, WEB), excluyendo `plu` (PK) y los campos `rel_tipo=detalle_multiple` (`label`, `proveedor`, `categorias` — esos no pasan por `Dic::updateFila()`, necesitarían su propio tratamiento). **Backend** (`ProductoController.php`): `apiCopiarCamposAction` (catálogo de campos copiables), `apiCopiarDesdeAction` (valores del producto origen, ya filtrados a los campos permitidos), `apiCopiarAplicarAction` (aplica el subconjunto elegido). **El servidor nunca confía en la lista de campos que manda el cliente** — `apiCopiarAplicarAction` siempre vuelve a filtrar contra `permite_copiar=1` antes de leer/escribir nada, verificado explícitamente con curl (mandar un campo no autorizado como `precio` junto a uno válido — el servidor lo descarta en silencio, `camposCopiados` refleja solo los válidos). Reutiliza `Dic::updateFila()` tal cual para aplicar — hereda gratis toda su validación (`valor_unico`, límites de longitud, normalización de tipos, bitácora) sin reimplementar nada. **Frontend**: panel `producto-copiar/[plu]` — input de PLU origen, checklist agrupado por pestaña (mismo agrupamiento que el editor genérico) con vista previa del valor de cada campo, todos pre-marcados, el usuario desmarca lo que no quiere antes de aplicar. **Verificado end-to-end**: curl local (incluyendo el caso de seguridad del campo no autorizado) y Playwright contra el despliegue real (`catalogo.sistemasmb.com`) — el checklist carga 46 campos agrupados correctamente con los valores del producto origen. Config exportada a `mbinvestructura` (141 campos con `permite_copiar` propagado, 6 acciones). --- **Ofertas (`maeofe`) — auditado, decisión explícita de NO migrar por ahora.** Resultó considerablemente más grande y acoplado de lo que sugería el plan original: - Maestro de 50 columnas con un campo virtual "tipo de oferta" (selector único en la UI) que en realidad son 8 columnas booleanas mutuamente excluyentes (`global`/`dosxuno`/`tresxuno`/`tresxdos`/`mitadprecio`/ `bonificacion`/`por_monto`/`mix_and_match`) — no encaja en el editor campo-a-campo sin lógica bespoke. - Detalle en dos tablas con redundancia real (`detofe` con columnas `regalo*` inline, `detofe_regalo` para "varios regalos" — coexisten según un flag del legado, no es error). - Motor de aplicación masiva por criterio SQL dinámico (`usa_criterio`/ `criterio`) que depende de `maegrd` — la misma dependencia que ya se descartó dos veces (Maeplu, Listas de precio). - **La aplicación real de la oferta al vender no vive en este repo** — está en `mbvb6/Comunes/Clases/clsOfertas.cls` (555 líneas), consumida por MBCaja (POS de escritorio). Migrar el CRUD de `maeofe` a Diccionario cambiaría solo la administración, no el comportamiento en caja. - Datos en `mbinvdiccionario`: 2 filas de `maeofe`, ambas de prueba (vigencia vencida en 2022/2023), 0 filas de detalle — no hay volumen real que consultar desde esta base. Si se retoma en el futuro, empezar por el plan reducido ya evaluado: maestro + panel bespoke de detalle simple (agregar/quitar productos uno por uno, sin motor de criterio ni "varios regalos"). --- **Fase 7 completa (2026-07-20) — Fórmulas/Producción (BOM).** Última fase del plan original — el subsistema más grande y complejo de toda la migración. Antes de construir se hizo una auditoría exhaustiva del editor legado (`/producto/formula/{id}`, `formulaTmp.html.twig` + `ProductoController::formula*Action`, ~1000 líneas entre las dos) que encontró **8 bugs reales**, confirmados leyendo el código (no sospechas). Decisión del usuario: corregirlos al migrar, no replicarlos. **Alcance**: editor de ingredientes + cabecera (incluye instrucciones de receta) + "copiar fórmula" reconstruida. Las instrucciones de receta pasaron por dos diseños: el primer intento portó los 4 campos sueltos del VB6 legado (temperatura/tiempo de mezcla/con-sin fuego, muertos en el BO web desde hace tiempo) — el usuario los encontró confusos y pidió reemplazarlos por un solo campo de **texto enriquecido** (HTML con formato + imágenes embebidas en base64), editado con un componente nuevo `RichTextEditor` (contentEditable + toolbar, sin dependencias nuevas) sobre `maefor.obs`, que por eso pasó de `varchar(255)` a `MEDIUMTEXT` (aplicado directo en ambas bases + agregado a `Instalacion.php` para que se propague a instalaciones de clientes nuevas). **Fuera de alcance a propósito**: distribución semanal (`maefor.lunes..domingo`) — la auditoría no encontró ningún proceso que la consuma dentro de `ProductoBundle`, y el usuario confirmó que tampoco la usa; y el subsistema de `ProcesosController.php` (importación masiva por Excel + recosteo/cuadre masivo, ~19000 líneas) — comparte las mismas 4 tablas pero tiene una implementación de cálculo **totalmente independiente** (ni siquiera llama a `Producto::recalcularFormula()`), queda intacto. **Los 8 bugs encontrados, y qué se hizo con cada uno**: 1. **IVA en el costeo — CORREGIDO** (decisión explícita del usuario): `Producto::recalcularFormula()` calculaba el "costo sin IVA" de la fórmula usando el % de IVA del producto FORMULADO para TODOS los ingredientes — matemáticamente incorrecto si un ingrediente exento se mezcla con uno gravado. Ahora cada ingrediente se destapa con su propio IVA antes de sumar, y el resultado se re-grava con el IVA del producto padre. Este fix vive en la clase de negocio compartida (`Producto.php`), no en el panel — también beneficia a cualquier otro caller fuera de esta migración. **Verificado matemáticamente**: con un ingrediente exento (IVA 0%, costo 100) en una fórmula de un producto con IVA 12%, el resultado correcto es sicosto=100/costo=112 (antes del fix: sicosto=89.29/costo=100, incorrecto). 2. **"Copiar fórmula" — RECONSTRUIDA corrigiendo 3 bugs** (decisión explícita del usuario): (a) el legado asignaba SIEMPRE `detfor_produccion` como tabla destino cuando el destino no tenía fórmula, sin importar el tipo del origen — ahora copia al mismo tipo que el origen; (b) el modo "fusionar ingredientes" hacía un `INSERT` ciego en `maefor` que **siempre fallaba con clave duplicada** cuando el destino ya tenía su propia fórmula — que es justo su caso de uso principal, la función estaba rota para su propósito real — ahora hace upsert real (**verificado**: fusionar hacia un producto con fórmula propia ya no falla, y el ingrediente compartido entre ambas fórmulas queda con la suma correcta de cantidades); (c) el checkbox "copiar cantidad de lote" no hacía nada (el valor se pisaba incondicionalmente) — ahora sí se respeta (**verificado**: con el checkbox desmarcado, el lote destino queda en 1, no el del origen). 3. **Bloqueo por existencia al eliminar fórmula — CORREGIDO**: el legado (`formulaEliminarAction`) no validaba nada antes de borrar toda la fórmula. El endpoint nuevo sí valida (mismo criterio real ya usado para conversión de tipo venta↔producción, `Producto::existenciasPorTienda()`). 4. **Validación de fórmulas cíclicas — AGREGADA** (no existía en el editor interactivo legado, solo en la carga masiva por Excel): el endpoint de agregar ingrediente ahora recorre la fórmula del ingrediente candidato (y la de sus propios ingredientes, etc.) hasta 20 niveles buscando el producto padre, antes de permitir agregarlo. 5. **Validación "el total no puede exceder la cantidad de lote" — AGREGADA** (existía en el VB6 legado, `frmProduccionFormulas.frm`, pero se perdió en el BO web): agregar/editar un ingrediente ahora la respeta. 6. El interruptor global `parametros_globales.modifica_formulas` nunca bloqueaba nada por un bug de comparación de tipos (`'N' == $array` siempre falso) — **no se portó**, sin UI que lo exponga tampoco, se deja fuera del alcance de esta fase (documentado como hallazgo, no como pendiente). 7. Asimetría de validación en "copiar fórmula" (bloqueaba si el destino tenía `detfor_produccion` pero no si tenía `detfor`) — corregida junto con el bug #2. 8. Bug de copy-paste en `formulaGrabarPorcentajeAction` (`if ($lunes == "")` debía decir `$domingo`) — irrelevante, esa función completa (distribución semanal) queda fuera de alcance. **Decisión de arquitectura (usuario) — sin tabla de borrador compartida**: el legado usa `detfortmp`, una tabla física global indexada **solo por `plu`**, no por usuario/sesión — si dos personas abren la fórmula del mismo producto, la segunda persona borra en silencio el borrador de la primera con solo abrir la pantalla. El panel nuevo no replica ese patrón: cada acción (agregar/editar/quitar ingrediente, guardar cabecera) escribe directo contra `detfor`/`detfor_produccion`, sin paso de "borrador" — mismo patrón ya usado en Localidades/Imágenes. **Backend**: 11 endpoints nuevos en `ProductoController.php`, todos reutilizando `catalogoAutenticar`/`catalogoCors` y las funciones de negocio existentes de `Producto.php` (`existenciasPorTienda`, `getUnidadBase`, `recalcularFormula`) sin reimplementarlas. Un detalle de diseño no trivial: el "tipo" de fórmula (venta/producción) se deriva de si `detfor`/`detfor_produccion` tienen filas — pero una fórmula recién creada (cabecera en `maefor`, cero ingredientes todavía) no tiene forma de que el servidor recuerde qué tipo se eligió, así que el endpoint de "agregar ingrediente" acepta un `tipo` opcional como respaldo para ese caso específico (el frontend lo manda mientras el servidor todavía no puede derivarlo de las tablas). **Frontend**: panel `producto-formula/[plu]` — pantalla de elegir tipo si no tiene fórmula, cabecera con instrucciones de receta, tabla de ingredientes con buscador tipo autocompletar, costo sin/con IVA y precio de venta (gateados por permiso `vercosto`), sección "copiar de otra fórmula", eliminar fórmula completa. **Bug encontrado en pruebas (no en el código de negocio, en el render)**: `