El Gestor de Gestoría y su Gerente
Levantamiento a partir de entrevistas, visita de campo, transcripciones, capturas reales de Oracle y, ahora, revisión completa de las maquetas funcionales de ambos tableros contra toda la documentación. Documento vivo: se actualiza en cada sesión.
Resumen y planQué hemos levantado y hacia dónde vamos
Este documento reúne todo lo capturado sobre la operación del Gestor de Gestoría y su Gerente en FANASA: los cuatro procesos que gestionan (devoluciones diarias, especiales, faltantes facturados y aclaraciones de saldo), los sistemas que usan hoy, y el prototipo funcional construido como base de discusión.
Sesiones y fuentes ya cubiertas
Validación del tablero de Gerentes de Gestoría con Joel
Primera validación del diseño del tablero del Gerente.
Mónica Hernández Morales — Gerente de Zona
Primer levantamiento del flujo de devoluciones y del rol de Gestor.
Héctor
Confirma responsabilidad del Gerente (no del RV) en aclaraciones de saldo.
Kenia
Confirma el mismo punto de aclaraciones de saldo desde otra zona.
Joel — weekly de equipo de ventas (transcripción completa)
Devolución especial por cadena, mecánica de lista de precios y RMA, escenarios de descuadre, propuesta de contenido del tablero.
Wan + Ale — sesión de Oracle
Recorrido en vivo por Oracle: estados reales, capturas de pantalla, catálogo de motivos FNA-DVL-xxx.
Sofía — día completo en campo con un Gestor
Validación de la maqueta contra la operación real; hallazgos de UX y de datos faltantes.
Crédito y Cobranza — Giannina (Farmacias del Ahorro) y Diego (Benavides/YZA)
Aclara la mecánica real de los reportes de saldos, descarta un feature innecesario (folios semanales) y confirma que "Saldos pendientes de aclarar" es principalmente una vista del Gerente.
Revisión del MVP — solicitudes nuevas
Generalizar motivos de incidencia, RMA visible en tarjetas, lista de precios accesible desde Resumen, merma potencialmente diaria, separar 3 escenarios de error de descuadre con responsable.
Revisión completa de las maquetas reales — Gestor + Gerente
20 pantallas revisadas pantalla por pantalla contra toda la documentación. 7 hallazgos de coherencia detectados (ver sección 13).
Recolección de documentos operativos reales
Geo-recorridos (Stratos), Notas de crédito, Reportes semanales (Devoluciones/Faltantes/Rechazos), correo de Devolución Especial con carátulas y calendario por cadena, y el reporte real de Aclaraciones de saldo de Benavides.
Checklist de datos para TI — construido y validado
12 solicitudes a TI, 102 campos únicos sin duplicar, y un anexo de 20 hallazgos sobre catálogos y motivos en conflicto o incompletos (ver sección 14).
TI — solicitud formal de datos
Con el checklist ya construido (sección 14) como base para que TI entienda el proyecto y qué datos necesitamos extraer de Oracle/EDA/Stratos.
El Gestor y su Gerente, al centroLos dos roles para los que se diseña esta herramienta
El Gestor opera en campo devoluciones, faltantes y aclaraciones de sus cuentas; su Gerente dirige el equipo, tiene acceso a Oracle y es el responsable formal de las aclaraciones de saldo. Crédito y Cobranza es el tercer actor del ciclo.
El Gestor · en campo
- Visita farmacias de sus cuentas asignadas según plan de trabajo semanal
- Transmite devoluciones y faltantes en la EDA
- Empaca y encincha físicamente lo que devuelve
- Da seguimiento a folios, RMA y devoluciones especiales por cadena
El Gerente · dirige el equipo
- Ve el cumplimiento de visitas y tareas de todo su equipo de Gestores
- Da seguimiento a los "3 escenarios de descuadre" cuando algo no cuadra
- Es el responsable formal de las aclaraciones de saldo (no el Gestor)
- Firma / autoriza procesos extemporáneos junto con Gerente Territorial
- Es quien tiene acceso directo a Oracle — el Gestor no
Crédito y Cobranza · el tercer actor
- Descarga semanalmente los reportes de Oracle
- Concilia y comparte discrepancias con Fuerza de Ventas
- Giannina — Farmacias del Ahorro · Diego — Benavides/YZA
- Rinde el ciclo completo: Gestor → Gerente → Crédito y Cobranza
Ejemplo real de plan de trabajo: Zona 59 · Alibry Sorcia Guerrero, Gerente de Zona Mónica Hernández Morales. Cifras exactas de cuántos Gestores y Gerentes existen en total — pendiente de confirmar.
Qué resuelve la GestoríaCuatro procesos, un mismo objetivo: mantener la cuenta del cliente en orden
Cuatro procesos con un mismo riesgo de fondo: si no se gestionan a tiempo, el cliente queda con un saldo que no coincide con lo esperado, y eso desgasta la relación comercial.
📦 Devolución día a día
Referenciada a factura. El motivo más común de contacto entre Gestor y farmacia.
📦 Devolución especial
Acuerdo por volumen con cuenta clave, por cadena, ligada a lista de precios.
❗ Faltante facturado
El cliente recibió menos de lo que se facturó — flujo distinto, pasa por Control de Inventarios.
💰 Aclaración de saldo
El síntoma final cuando algo de los tres procesos anteriores no se transmitió o liquidó bien.
Las cuentas claveConfirmado por Joel
Farmacias del Ahorro, Benavides, FEMSA y FESA. FESA es empresa hermana de FANASA dentro de Grupo FANAFESA — comparte cuentas y formatos, no es una cadena de farmacias.
FESA es la empresa hermana de FANASA dentro de Grupo FANAFESA — no es una cadena de farmacias, gestiona algunas cuentas clave junto con FANASA. Esto es relevante porque parte del directorio de contacto y de los formatos de reclamación son compartidos entre ambas.
Devolución día a díaConfirmado por Wan/Ale + recorrido en Oracle
Referenciada a factura. El Gestor transmite en EDA (nace el RMA), el operador recolecta al día siguiente, llega a almacén y ~24h después se genera la nota de crédito. Tiempo ideal 8–10 días; el cuello de botella real es almacén, no la recolección.
Cliente solicita devolución — referenciada a factura
Gestor transmite en EDA
Se genera el RMA desde este momento — folio identificador de todo el proceso.
Operador recolecta al día siguiente
Llega a almacén — acuse de recibo
Nota de crédito
Internamente Oracle marca "Cerrados" + "Estado Usuario: Aprobada"; la NC muestra Saldo 0.00 cuando ya liquidó.
Devolución especialWan/Ale + transcripción completa de Joel
Acuerdo por volumen con cuenta clave, por cadena (no por sucursal), ligado a una lista de precios que cambia cada mes. Si almacén jala la lista equivocada, es la causa más común de aclaración de saldo. El descuadre tiene 5 categorías, cada una con responsable distinto.
Acuerdo por volumen con cuenta clave — NO referenciada a factura
Va por cadena, no por sucursal: 1–2 especiales por cadena al mes. En el extremo, un Gestor puede acumular hasta 8/mes sumando cadenas.
Mismo flujo Oracle que la diaria
El RMA se asocia a la lista de precios (Excel pintado en EDA, cambia cada mes) en el momento en que almacén "jala" esa lista — no desde la transmisión. Joel pidió, tras el MVP, acceso rápido a la lista vigente desde Resumen — es la fuente de error más común.
Si almacén jala la lista de precios equivocada…
El cliente queda sobre o sub-bonificado frente a lo que su corporativo esperaba — esta es la causa más común de aclaración de saldo formal (ver sección 08).
El catálogo de motivos especiales de arriba no coincide con la carátula real
Revisando el correo real "Devolución Especial Benavides Jul 2026" (carátulas por sucursal + calendario), el catálogo que usa FANASA en la práctica es Excedente, Límite de Caducidad, Especial Exce/Cad, Rebalanceo — "Rebalanceo" no existe en el curso oficial de arriba. Pendiente de confirmar con FANASA cuál es el vigente.
Categoría de descuadre — 5 escenarios, no 3
Joel pidió separar estos escenarios sin mezclarlos, cada uno con responsable distinto. Se sumó un quinto: "Motivo erróneo" — el Gestor captura el motivo equivocado en la EDA, incidencia ya documentada en el Curso de Devoluciones como "devolución mal transmitida".
| Escenario de descuadre | Responsable | ¿Dato automático de Oracle? |
|---|---|---|
| Lista de precios mal elegida | Gestor → escala a Crédito y Cobranza | Sí — la única de las 5 |
| Motivo erróneo (captura en EDA) | Gestor | No |
| Producto físico incorrecto (SKU/presentación o mal estado) | Gestor | No — arqueo manual |
| Error de almacén (declara mermado sin serlo) | Almacén | No |
| Por confirmar | Transitorio | — |
Categorización propia de Hologram — pendiente validar con Joel antes de fijarla en el tablero.
Faltante facturadoWan/Ale + captura real de Oracle
El cliente recibió menos de lo facturado. Pasa por Control de Inventarios; el identificador desde el día 0 es el RCL, no el RMA (que solo nace si CI libera). La autorización de captura extemporánea aún no está reflejada en el tablero.
Cliente reporta faltante — referenciado a factura
Soporte: anotación de "bulto faltante" en la guía de reparto.
Gestor transmite en EDA
Plazo estándar 3–5 días. Hasta 30 días con autorización de Gerente Territorial + Gerente de Zona; +30 días requiere también Gerente Admón. de Ventas.
Notificación automática a Control de Inventarios
CI dictamina
La maqueta muestra RMA como folio principal — debería ser RCL
El folio RCL nace de inmediato al transmitir en EDA (día 0); el RMA no existe hasta que CI libera, días o semanas después. Corrección pendiente de aplicar.
Autorización de captura extemporánea
El umbral de días (5/30) lo calcula Hologram solo. Falta confirmar si la autorización queda registrada en algún sistema o solo ocurre fuera de él (correo/Teams).
Aclaración de saldoEl síntoma final de los otros tres procesos — mecánica confirmada por Crédito y Cobranza el 30 jul
Vive en el Tablero del Gerente (responsable formal), aunque el Gestor la ve de forma informativa. El monto correcto es la diferencia sin conciliar (DIF PZAS/DIF IMP), no el importe total — confirmado contra el reporte real de Benavides.
Se liga al estado de cuenta / factura
Si el Gestor transmitió bien la devolución/faltante, la factura queda en $0 automáticamente.
Crédito y Cobranza descarga y concilia reportes de Oracle — semanalmente
Dos reportes independientes: saldos/discrepancias (a Ventas) y recolección de folios (Benavides/YZA) — no deben confundirse.
Benavides/YZA usan folio de entrada · Ahorro usa factura firmada
Prioriza por antigüedad · resuelve Crédito, responsabilidad es del Gerente
No del RV/Gestor (confirmado por Héctor, Kenia y Crédito). Meta: Farmacias del Ahorro no debe superar 1 mes vencido.
Vive en el Gerente, visible también para el Gestor de forma informativa
Responsable formal: el Gerente. Aparece además de forma informativa para el Gestor —sin contar como tarea suya— respaldado por las minutas de Mónica y Kenia. El monto correcto es la diferencia sin conciliar (DIF PZAS/DIF IMP). "Folios semanales de Benavides" se descartó: la EDA ya permite cotejar factura vs. entrega física.
Motivos de diarias y comentarios abiertos
El catálogo de motivos solo está confirmado para especiales (códigos equivalentes / devolución irreal / mal referenciada); el de diarias sigue sin confirmar. El reporte real también trae comentarios abiertos de Crédito y Cobranza / Ventas — no confirmado si aplican igual a ambas cadencias.
Motivos y estados — el catálogo realDe curso oficial + capturas de Oracle, no de memoria
Catálogos reales de motivos y estados por proceso, confirmados contra el curso oficial y capturas de Oracle. Incluye un conflicto detectado (Estado vs. Estado Usuario). El detalle completo de los 20 hallazgos vive en el checklist de TI (sección 14).
Motivos normales (Curso_Devoluciones.pdf)
Motivos especiales (Curso_Devoluciones.pdf)
Códigos Oracle confirmados por captura real: FNA-DVL-001 Decisión de ventas · FNA-DVL-004 Error cliente · FNA-DVL-005 Falla mecánica · FNA-DVL-006 Mal estado · FNA-DVL-011 Excedentes/Límite de caducidad.
| Proceso | Estados reales confirmados |
|---|---|
| Devolución (diaria/especial) | Ingresada → Registrada → Cerrada / Cancelada |
| Faltante facturado | En Trámite Por CI → En Proceso Con CI → Liberada Por CI / Rechazada Por CI / Cancelada / Forma económica |
Ojo: la etiqueta de UI validada en campo por Sofía (Transmitida/Recolectada/Ingresada/Nota de crédito/Cancelada) no coincide 1:1 con este catálogo de Oracle — falta definir cuál se usa como fuente de verdad del tablero.
Oracle trae un segundo campo, "Estado Usuario", además de "Estado"
En la captura real del folio 5379107: Estado = "Cerrados" + Estado Usuario = "Aprobada". No está confirmado si son sinónimos o dos campos independientes — pendiente de aclarar con TI.
El levantamiento completo de catálogos y motivos —incluyendo los que están incompletos o en conflicto entre fuentes— vive ahora en un documento aparte: el checklist de datos para TI (sección 14), con 20 hallazgos documentados uno por uno.
Sistemas de hoyEDA · Oracle · Stratos
EDA transmite, Oracle es la fuente de verdad de estados (actualiza diario), Stratos geolocaliza (actualiza al día siguiente). La sincronización del RMA se puede verificar en menos de 24h.
EDA
App móvil del Gestor: transmite devoluciones, faltantes y motivos. Punto de entrada de todo el proceso.
Oracle
ERP — estados, RMA, notas de crédito, catálogo de motivos. Se actualiza al momento / diario (confirmado por Wan) para devoluciones y faltantes.
Stratos
Geolocalización de recorridos. Se actualiza hasta el día siguiente — más lento que Oracle.
Verificación de sincronización del RMA: es posible en menos de 24h vía EDA (Joel) — es distinto y más rápido que el proceso de bonificación/nota de crédito, que sigue el ritmo más lento de Crédito y Cobranza.
El hueco: todo existe, pero disperso en 4 sistemas
Hologram es el intermediario autorizado: no da acceso crudo a Oracle, trae la información ya filtrada y a tiempo a quien la necesita — algo que la propia Crédito y Cobranza (Giannina) ya confirmó que le ahorraría tiempo real.
Acceso confirmado (30 jul): Gestores no tienen acceso directo a Oracle — decisión deliberada por licencias y control de uso. Gerentes de Zona sí lo tienen.
El tablero del Gestor — la appMaqueta funcional ya construida y revisada
Esto es lo que ya está construido: un prototipo funcional de 10 pantallas que resuelve, para el Gestor, la pregunta que hoy nadie le responde a tiempo — "¿lo que hice hoy en campo ya está bien en el sistema, o se me va a quedar atorado?" Cada pantalla necesita datos concretos de Oracle, EDA o Stratos — por eso este entregable es la base de la solicitud formal a TI.
Datos que este entregable necesita de TI para dejar de ser un mockup y convertirse en producto real: estado y fecha del RMA/RCL por folio, catálogo de motivos vigente (FNA-DVL-xxx), lista de precios vigente por cadena/mes, estados de Control de Inventarios con justificación/rechazador, y georreferencia de visitas (Stratos). El detalle completo, campo por campo, vive en el checklist de la sección 14.
El tablero del Gerente de Gestoría — la appMaqueta funcional ya construida y revisada
Misma lógica que el del Gestor, pero a nivel equipo: el Gerente necesita ver quién está por debajo de ritmo, qué saldos hay que aclarar y dónde escalar, sin volverse "analista de reportes".
Hallazgos al revisar las maquetas20 pantallas contra toda la documentación — 11 ago 2026
7 hallazgos detectados al revisar ambas maquetas pantalla por pantalla contra minutas, capturas de Oracle y reportes reales — desde catálogos mezclados hasta datos de ejemplo inconsistentes.
| Motivos de "Reportar Incidencia" mezclados con motivos de rechazo de devolución, en vez de motivos de "no pude hacer la visita" | Corregido |
| Vocabularios de estatus mezclados entre Devolución / Faltante / Aclaración — cada uno tiene su propio catálogo | Corregido |
| Aclaraciones de saldo aparecía como tarea propia del Gestor — la responsabilidad es del Gerente | Resuelto |
| Faltante Facturado mostraba RMA como folio principal, debería ser RCL | Corregido |
| Categoría de descuadre — de 3 a 5 escenarios, se sumó "Motivo erróneo" | Ampliado |
| Porcentajes de ejemplo no cuadraban con el total — placeholder a corregir con datos reales | Dato de ejemplo |
| Devolución especial no desglosaba por motivo; faltaban Capacitación y Rechazos como fuente de datos | Hueco |
El checklist de datos para TIDocumento aparte, listo para la reunión
Documento aparte (checklist_datos_FANASA.html) con 12 solicitudes a TI, 102 campos únicos y 20 hallazgos documentados en dos anexos — listo para la reunión con TI.
12 solicitudes a TI
Un bloque por reporte/fuente real (Devoluciones, Faltantes, Notas de crédito, Devolución especial, Aclaraciones, Geo-recorrido, Merma, Rechazos, Reclamación manual, Motivos de incidencia, Capacitación, Catálogo de clientes), con campos, granularidad, cómo llega hoy y qué pedir.
102 campos únicos
Los campos que se repiten entre reportes (Zona, Cuenta, Factura, Cincho, RMA...) se agrupan aparte en "Campos comunes" — se piden una sola vez, no 6 u 8 veces.
Nivel de datos por apartado
Tabs Gestor/Gerente que muestran, para cada pantalla del tablero, qué % de sus datos ya está solicitado — calculado automáticamente sobre el mismo checklist.
Dos anexos de hallazgos
20 catálogos y motivos documentados con su estado (conflicto entre fuentes / incompleto / propuesta nueva de Hologram) y qué pedir exactamente — de aquí salió, por ejemplo, el hallazgo de las 5 categorías de descuadre y el conflicto del motivo de devolución especial.
Documento vivo con checkboxes que se guardan en el navegador — se puede marcar en vivo durante la reunión con TI qué se va confirmando.
Lo que aún no sabemosLa lista que llevamos a Crédito y Cobranza y a TI
13 temas abiertos, de acceso a Oracle a vocabulario compartido con Crédito — la mayoría ya resueltos o acotados, algunos siguen esperando confirmación.
| Acceso técnico real a Oracle — con qué frecuencia puede Hologram consultarlo | Clave |
| Cuántas listas de precios están vigentes — confirmado que cambian por cadena y motivo, falta el mecanismo de consulta | Clave |
| Relación completa entre "motivos de negocio" y códigos FNA-DVL-xxx | Pendiente |
| Vocabulario común entre Crédito, Ventas y Hologram ("saldos" significa distinto según quién lo diga) | Pendiente |
| Motivos de aclaración de saldo para las DIARIAS (solo especiales está confirmado) | Pendiente |
| Si la autorización de captura extemporánea de faltantes queda registrada en algún sistema | Pendiente |
| Duplicidad con "Fanasis" (Sergio) — reunión de coordinación pendiente | Por confirmar |
| Taller aparte sobre hallazgos de campo en Bajío/Guadalupe | Por confirmar |
| Si Rechazos y Reclamación Manual entran al alcance del tablero | Por confirmar |
| Cadencia de devolución especial — por cadena, 1–2 veces al mes | Resuelto |
| Dónde vive Aclaración de Saldos — Gerente, informativa también para el Gestor | Resuelto |
| Necesidad de "folios semanales" — descartada, ya cubierta por EDA | Resuelto |
| Identificador primario de un faltante facturado — es el RCL, no el RMA | Resuelto |
Camino al MVP
Reunión con Crédito y Cobranza
Confirmó la mecánica real de saldos y descartó un feature innecesario (folios semanales).
Revisión de coherencia de ambas maquetas
20 pantallas revisadas, 7 hallazgos corregidos o documentados (sección 13), y checklist de datos para TI construido (sección 14).
Reunión con TI — solicitud formal de datos
Con el checklist (sección 14) como guía, para que TI entienda qué estamos construyendo y para qué necesitamos cada dato de Oracle/EDA/Stratos.
Aplicar correcciones a las maquetas
RCL como identificador primario de faltantes, catálogo correcto en "Reportar incidencia", desglose de devolución especial por motivo, y las 5 categorías de descuadre.
Tablero de Mixtos — Gestores y Gerentes
Perfiles que llevan venta y gestoría a la vez, tanto a nivel Gestor/RV como a nivel Gerente. Joel ya advirtió: mezclar la vista de representante de ventas con la de Gestor puede volverse "muy complicado" — hay que diseñarlo con cautela, no fusionar de golpe.