LIFE·IN·CO / Portal Puig · Pedidos y Facturación
Fase 1 · Diseño cerrado Corte 15 sep 2026
Moore Colombia · Puig · LIFE·IN·CO

Portal de Pedidos y Facturación

Diseño funcional cerrado y navegable: 36 pantallas para 8 perfiles, la máquina de 14 estados del pedido, parámetros por cliente, posventa con doble aprobación e integración por API con Affinity Cloud y Pharex. Un solo lugar con el estado real del proyecto para Moore y Puig.

36
Pantallas diseñadas
8
Perfiles con menú propio
14
Estados del pedido
33
Reglas de negocio
20
Canales en la matriz de clientes
0
Decisiones abiertas
Avance de la fase
Diseño funcional
100 %
Diseño aprobado en la sesión de revisión: demo navegable v2 con 8 perfiles y simulador de Affinity y Pharex. Decisiones abiertas: 0. Las definiciones de Fase 0 quedaron cerradas el 15 de septiembre.Abrir el demo navegable v2 ↗
Actividad eliminada
60%
de 99 actividades
Existen porque el pedido nace desestructurado. No se automatizan: dejan de tener razón de ser cuando el portal captura en el origen.
Paradas humanas del flujo
Cuatro, cada una con dueño
Diferencia de precio (comercial), dirección no estándar (analista), bloqueo por cartera (Finanzas de Puig) y nota crédito en dos etapas (Finanzas de Puig y líder de Moore). Todo lo demás avanza por validación automática o por respuesta de un sistema externo.

Arquitectura de cuatro capas

CAPA 1
Experiencia
Presentar y capturar, cero lógica. Ocho perfiles sobre el mismo shell: comercial y POS de Puig, Finanzas de Puig, analista y líder de Moore, administrador, auditor y dirección.
CAPA 2
Servicios de dominio
Aquí vive toda la regla de negocio: pedidos, catálogo, operador, facturación, posventa y documentos.
CAPA 3
Trabajos programados
Catálogo diario · consulta de trazabilidad en Affinity · emisión por ventana del cliente · conciliador semanal · informe diario antes de las 10:00.
CAPA 4
Datos y gobierno
Base del portal · espejo de maestros en solo lectura · bitácora inmutable · repositorio documental por pedido.

Sistemas y fuente de verdad

Affinity Cloud · ERP
API REST · manda sobre SKU, precios y terceros
Lee: productos, inventarios, terceros, precios, centros y subcentros de costo, proyectos, oficinas, bodegas, monedas y tasas, más la trazabilidad documental de cada pedido.
Escribe: pedido 020 con referencia externa única, remisión 030, factura 045 y nota crédito. Simula impuestos sin crear documentos.
Confirmado por PwC · 8 sep 2026
Pharex · operador
Manda sobre inventario y cita
enviar_pedidoAPI REST
consultar_inventarioen línea · sin contrato
recibir_confirmadaExcel
recibir_cita_entregasin contrato
recibir_podmanual
Contrato de creación de pedidos recibido (APIPED-001). Las demás operaciones siguen sin contrato y degradan con marca visible.
Canales degradados
Correo · WhatsApp · FTP
Quedan como canal de notificación. El estado del pedido ya no vive ahí: reemplazan el pantallazo de las 7:30. Entra por SSO de Microsoft Entra con MFA (AD-PL-11); Puig y el operador con usuario externo acotado.
02 · Fases

Ruta del proyecto

Cinco fases: levantamiento y diseño cerrados, construcción es la siguiente. Cada estación declara su entregable y la condición que la cierra: sin esa condición no avanza, aunque el calendario diga otra cosa.

01
Levantamiento
Cerrada
02
Diseño funcional
Aprobada · demo v2
03
Construcción
Siguiente
04
Migración Affinity
1 nov 2026
05
Salida a operación
Con muestra de auditoría
FASE 01
Levantamiento
99 actividades del proceso actual mapeadas, 33 reglas de negocio rastreadas y 7 restricciones de Affinity documentadas.
Cerrada
FASE 02
Diseño funcional
Demo navegable v2: 36 pantallas para 8 perfiles, máquina de 14 estados, parámetros por cliente, posventa con doble aprobación y simulador de Affinity y Pharex.
Aprobada · 15 sep
FASE 03
Construcción
Capa de servicios de dominio primero, experiencia después. Se construye sobre la API REST de Affinity Cloud y la API de pedidos de Pharex, con degradación manual desde el día uno.
Siguiente · 0 decisiones abiertas
FASE 04
Migración Affinity
Puig migra a Affinity Cloud el 1 de noviembre de 2026 (D18). Siigo se soporta solo como modo de transición hasta esa fecha (P7). Falta el plan de corte de los pedidos en vuelo.
1 nov 2026
FASE 05
Salida a operación
La muestra documental de octubre sale del portal con un clic: OC, Z, S, hoja del operador, remisión, factura y POD atados al pedido (P6).
Condición de cierre
03 · Pantallas

Catálogo del demo v2 · 36 pantallas

Ocho perfiles sobre el mismo shell, cada uno con su menú. Las pantallas P vienen del diseño original; las N se agregaron en la v2. Nada existe sin una regla que lo sostenga.

Wireframes originales en Canva ↗ Abrir el demo navegable v2 ↗
Confirmada por el levantamiento Depende de una decisión abierta Restricción dura del sistema

Portal comercial · Puig

5 pantallas · más variantes POS
P-03
Mis pedidos
Pestañas: todos, borradores, esperando mi aprobación, en curso, cerrados. Alcance por cliente asignado. Incluye la vista propia del comercial sobre cada pedido y sus backorders.
P-04
Crear pedido · cabecera
Al elegir cliente se cargan sus parámetros de P-17 y se muestran antes de pedir. Alerta de cartera si está en mora, con check obligatorio. OC única por cliente.
P-05 · nodo crítico
Líneas y validación
Barra de búsqueda con inventario Pharex en vivo. El armado no se interrumpe: cierre en tres canastas — con inventario, backorder, solicitar creación.
P-08 · nodo crítico
Requiere tu OK
Aprobar sigue a P-07; rechazar quita la línea y vuelve a borrador. Única decisión humana del camino feliz.
P-14
Solicitar referencia
El portal solicita, nunca crea. Accounting de Puig crea en Affinity; el sincronizador cierra la solicitud y la línea cae al backorder de esa OC.

Consola operativa · Moore

10 pantallas
P-02
Tablero operativo
Operación del día sin cortes: se ordena por antigüedad contra el objetivo de respuesta de 2 horas (D17). Tarjetas clicables que filtran la tabla.
P-07
Cola de envío
Envío en lote. Referencia duplicada en el consecutivo: consolidar cantidades o separar en dos.
P-08 · nodo crítico
Bandeja de novedades
Comercial ve precio, analista ve todo. Reintentar reencola en P-11; escalar a IT deja rastro.
P-09 · hub
Detalle y trazabilidad
Líneas · documentos · trazabilidad · novedades · posventa. Descarga el paquete .zip del pedido.
P-10
Puente con el operador
Salud de la integración. Confirmada parcial: ver diferencias, aceptar y generar S, crear backorder.
P-11 · nodo crítico
Cola de facturación
Previsualización obligatoria con la simulación tributaria de Affinity. Reintento con la misma clave de idempotencia; nunca duplica la factura.
P-12
Solicitud de nota crédito
Motivo → panel de consecuencias. Alcance total o parcial por línea. Pasa por Finanzas de Puig y luego por el líder de Moore; los rebates saltan la primera.
P-13 · nodo crítico
Gestión de posventa
Solicitadas · en revisión · bloqueadas · hechas. Doble documento con casilla de “hecho”, responsable y hora.
P-15
Backorder
Fuera de la secuencia, a propósito. “Convertir en pedido” crea uno nuevo y entra por la cola de envío.
P-19 · P-20
Reportes y conciliación
Día, mes, periodo, YTD. Conciliación semanal Moore vs. operador con causa inferida de cada diferencia.

Nuevas en la v2 · N-01 a N-16

16 pantallas · 4 perfiles nuevos · diseño aprobado
N-01 Comercial
Cierre del pedido
Una orden de compra se ramifica en pedido, backorder y solicitudes de referencia, y el cierre los nombra en lenguaje comercial.
N-02 Comercial · POS
Acuse
Confirma qué se creó con cada cierre: consecutivos, remisiones y facturas que van a salir.
N-03 Comercial
Avisos por correo
El comercial elige qué eventos le llegan por correo. El correo avisa con enlace; el estado vive en el portal.
N-04 Comercial
Detalle del pedido
Vista propia del comercial: en qué va, cuándo llega y qué le falta hacer. Sin vocabulario del ERP.
N-05 Finanzas Puig
Bandeja de aprobaciones
Finanzas de Puig aprueba la etapa Puig de cada nota crédito y los cambios de plazo de pago (D15, D23).
N-06 Finanzas Puig
Cartera y bloqueos
Libera o sostiene el bloqueo por cartera, con el dato del módulo de cartera de Affinity. Distinto de la alerta de mora en P-04, que avisa pero no frena (D25).
N-07 Finanzas Puig
Reportes financieros
Facturado, notas crédito por motivo y cartera, con el mismo dato que ve Moore.
N-08 Líder
Supervisión
Carga por analista, pedidos vencidos contra el objetivo de 2 horas y reasignación de trabajo.
N-09 Líder
Aprobaciones etapa Moore
Segunda aprobación de la nota crédito, entre la emisión contable y la electrónica (D23).
N-10 Admin
Salud del sistema
Estado de las integraciones con Affinity y Pharex, latencias y errores por operación.
N-11 Admin
Ruteo y SLA
Quién recibe cada tipo de novedad y en cuánto tiempo escala. Todo sube al líder salvo el cambio de dirección (D27); los SLA acordados se cargan aquí (D15).
N-12 Auditor
Consulta de pedidos
Búsqueda de solo lectura para el auditor, con acceso al detalle y a la bitácora.
N-13 Auditor
Paquete de auditoría
Muestra por rango, cliente o aleatoria y descarga del expediente: OC, remisión, factura y confirmada.
N-14 Dirección
Tablero ejecutivo
Para el comité: cuánto se facturó, qué tan rápido responde la operación, dónde se atasca y cómo va la migración.
N-15 Dirección
Reportes agregados
Los reportes de todas las áreas, agregados, sin acceso a la operación.
N-16 Demo
Simulador de sistemas externos
Solo del demo: provoca respuestas de Affinity y Pharex (acuse, error, silencio, cita) y mueve el reloj para probar cada flujo.

Acceso y administración

5 pantallas
P-01
Login y shell
SSO de Entra. El menú se construye del rol en el servidor. Buscador global por consecutivo, OC, referencia o NIT.
P-16
Espejo de maestros
Solo lectura, sin botón de editar. Único botón de escritura: forzar sincronización.
P-17 · nodo crítico
Parámetros por cliente
Gobierna P-04, P-05, P-07, P-11 y P-14. Agregar un sexto cliente es llenar esta ficha, no rediseñar pantallas.
P-18
Usuarios y roles
Define el menú de P-01 y el alcance por cliente de P-03. El administrador no opera pedidos.
P-21
Bitácora y auditoría
Muestra por rango, cliente o aleatoria → genera .zip. Cada evento enlaza a P-09.
Documento de diseño · Fase 1 cerrada · corte 15 sep 2026

Especificación funcional completa

Las pantallas con su especificación, la máquina de estados del pedido y de la nota crédito, el catálogo de parámetros por cliente, las 33 reglas de negocio y, desde septiembre, lo que PwC y Pharex confirmaron de sus APIs. El demo navegable v2 es la referencia visual.

Abrir los documentos de diseño en Drive ↗
PARTE 1
Fundamentos
Principios, permisos, arquitectura, máquinas de estado
PARTE 2
Pantallas P-01 a P-21
Qué hace, componentes, retos y qué actividad elimina
PARTE 3
Parámetros y reglas
Multi-cliente por ficha, 33 reglas rastreables
PARTE 4
Decisiones abiertas
Lo que depende de Moore, PwC o Pharex
Confirmado por el levantamiento Depende de una decisión abierta Restricción dura del sistema Paso manual con marca visible
Parte 1 · Fundamentos

Los siete principios de diseño

P1
El error se mata en el origen
El 60 % de las 99 actividades existe porque el pedido nace desestructurado. No se automatizan: dejan de tener razón de ser.
P2
Una fuente de verdad por dato
Affinity manda sobre SKU y precio. El operador sobre inventario. El portal sobre el flujo. Cero Excel paralelos.
P3
El correo deja de ser el canal
Correo, WhatsApp y FTP quedan como notificación. El estado vive en el portal y es el mismo para las dos partes.
P4
Una sola decisión humana
La aprobación de una diferencia de precio. Todo lo demás es validación automática o generación determinística.
P5
Separación de funciones
Quien crea el pedido no crea el producto ni fija el precio. El portal solicita, nunca crea: «serían juez y parte».
P6
Cada pedido arma su auditoría
OC, Z, S, hoja del operador, remisión, factura y POD atados al pedido. La muestra de octubre sale con un clic.
P7
Se diseña contra Affinity
Puig migra a Affinity Cloud el 1 de noviembre. Siigo se soporta solo como modo de transición, con fecha de caducidad explícita.
LECCIÓN DE EVA
Nada bloquea el flujo
Ninguna capacidad faltante bloquea: degrada a captura manual con marca visible. Es la lección directa del fracaso de Eva.

Roles y matriz de permisos

El menú se construye del rol en el servidor. Ocho perfiles: el comercial ve su cartera y la de quien respalda (D01); Finanzas de Puig y Dirección entran como perfiles propios.

Objeto
Comercial
Orig. POS
Finanzas Puig
Analista
Líder
Admin
Auditor
Dirección
Pedido propio
Crea y edita en preparación
Crea pedidos POS
Consulta
Ve todos, edita y anula
Igual que el analista
No opera pedidos
Consulta
Consulta agregada
Aprobación de precio
Aprueba la de su cartera
No
No
Escala, no aprueba
Aprueba en ausencia
No
Consulta
No
Backorder
Crea
No · genera novedad al analista
No
Atiende y convierte
Atiende y convierte
No
Consulta
Consulta
Solicitud de referencia
Crea
Crea
No
Crea
Crea y hace seguimiento
No
Consulta
No
Envío al operador
No
No
No
Sí
Sí
No
No
No
Disparo de facturación
No
No
No
Sí
Sí
No
No
No
Nota crédito
Solicita en lenguaje comercial
No
Aprueba la etapa Puig
Solicita y gestiona
Aprueba la etapa Moore
No
Consulta
Consulta
Bloqueo por cartera
Reconoce y continúa
No
Libera
Consulta
Consulta
No
Consulta
Consulta
Parámetros de cliente
No
No
No
Consulta
Edita
Edita
Consulta
Consulta
Usuarios y roles
No
No
No
No
No
Edita
Consulta
No
Espejo de maestros
No
No
No
Consulta y empareja
Consulta y empareja
Edita
Consulta
No
Bitácora
Sus eventos
Sus eventos
Sus eventos
Todos
Todos
Todos, sin editar
Todos
Sin acceso
Paquete de auditoría
No
No
No
Genera
Genera
Genera
Genera y descarga
No
Reportes
Los suyos
No
Financieros
Operativos
Operativos y de equipo
Técnicos
De auditoría
Todos, agregados
QUIÉN LO EJERCE HOY
Comercial: Alejandra y Luciana. Originador POS: Karen y Juliet (Pharex). Finanzas: equipo de Puig. Analista: Valentina y Daniela. Líder: Claudia y Tatiana. Auditor: Lina y auditoría externa.
RESUELTO · D01
Se reparten clientes y se respaldan cuando uno no está. P-03 usa cartera principal más respaldo.

Arquitectura de cuatro capas

Capa 1 · Experiencia presentar y capturar, cero lógica
Portal Puig · P-03 a P-05, P-08, P-14 Consola Moore · P-02, P-07 a P-13, P-15, P-19, P-20 Administración · P-16 a P-18, P-21 Vista del operador · condicional
Capa 2 · Servicios de dominio aquí vive toda la regla de negocio
Pedidos Catálogo Operador Facturación Posventa Documentos
Capa 3 · Trabajos programados lo que corre sin que nadie lo pida
Catálogo · diario, madrugada Inventario · en línea (D13) Emisión · cada hora Conciliador · semanal Informe diario · antes de las 10:00
Capa 4 · Datos y gobierno infraestructura de Moore, sin licenciamiento recurrente
Base del portal Espejo de maestros · solo lectura Bitácora inmutable Repositorio documental
Affinity Cloud · ERP
API REST · sin conexión a Legacy ni a la base
Lee: productos, precios por cliente, clientes, direcciones, centros de costo, facturas y movimiento del periodo.
Escribe: pedido (modelo 020), remisión, factura, devolución y nota crédito.
Restricciones absorbidas: A1 secuencia estricta · A2 autorización agrupada · A3 no previsualiza factura (se cubre con la simulación tributaria) · A4 nota crédito solo al 100 % (parcial en la hoja de ruta de posventa) · A5 NC externa no mueve inventario · A6 concepto DIAN exacto · A7 doble plantilla.
Operador logístico · Pharex
Manda sobre inventario y cita
consultar_inventarioen línea · sin contrato
enviar_pedidoAPI REST · APIPED-001
recibir_confirmadaparseo de Excel
recibir_cita_entregacaptura manual · sin contrato
recibir_podcarga manual
notificar_novedadcorreo
La columna derecha es la degradación cuando el operador no soporta la operación. Marca visible, nunca bloqueo.

Máquina de estados del pedido

Arriba el nombre del sistema, abajo lo que lee el usuario. Ningún botón del portal existe fuera de esta máquina.

BORRADOR
En preparación
Valida contra maestros. Nada sale del portal.
LISTO_PARA_ENVIO
Listo para enviar
Entra a la cola P-07.
ENVIADO_AL_OPERADOR
En el operador
Naranja: espera la confirmada.
CONFIRMADO
Con cita de entrega
Cita menos ventana = emisión.
CONFIRMADO_PARCIAL
Confirmado parcial
Es el caso normal, no la excepción. Saca backorder aparte (P-15).
EN_FACTURACION
Emitiendo
P-11 previsualiza antes de escribir.
FACTURADO
Facturado
Affinity devuelve el número.
CERRADO
Cerrado
POD cargado, paquete documental completo.
EN_APROBACION_DE_PRECIO
Requiere tu OK
Aprobar de un clic o quitar la línea y volver a borrador.
ERROR_FACTURACION
Error al emitir
Va a P-08 con el mensaje de Affinity.
ANULADO · CON_NOTA_CREDITO
Terminales alternos
Anulado solo antes de facturar.
Regla dura
Un pedido con al menos una novedad abierta está en rojo, sin importar su estado. El rojo manda sobre el naranja.

Máquina de estados de la nota crédito

Cinco de los siete escenarios reales son parciales. PwC confirmó el 8 de septiembre que la nota crédito parcial está en el alcance de posventa, sin fecha: el estado bloqueado sostiene el módulo mientras llega.

SOLICITADA → EN_REVISION → APROBADA → EN_EJECUCION → EJECUTADA RECHAZADA
ALCANCE TOTAL
Affinity acepta el 100 %
Ruta devolución de cliente: mueve inventario y cuenta. Sin intervención humana.
BLOQUEADA_SISTEMA · alcance parcial
5 de 7 escenarios reales
Registra líneas y cantidades, genera la instrucción de doble documento y rastrea la ejecución manual hasta el cierre.
Lo que el estado bloqueado hace posible
1 · REGISTRA
La solicitud completa, con líneas y cantidades.
2 · MARCA
Bloqueada por limitación del sistema contable, no por error del usuario.
3 · INSTRUYE
Genera el doble documento con valores y concepto DIAN exactos.
4 · RASTREA
Marcas de «hecho» por paso, con responsable y hora.
5 · CONECTA
Cuando Affinity habilite el parcial, se automatiza sin rediseñar ni volver a capturar.
Parte 2 · Pantallas

Especificación pantalla por pantalla

Nada de la interfaz existe sin una regla que lo sostenga. Cada ficha declara para qué existe, quién la usa, sus componentes con fuente de dato, los retos técnicos y qué actividad del proceso actual elimina.

P-01 Login y shell de navegación
Todos los roles · SSO Microsoft Entra
Qué hace. Autentica y arma el menú según el rol: el comercial de Puig ve tres opciones, el analista seis, el administrador las de configuración. El menú se construye del lado del servidor, no se oculta por CSS.
Componentes. Menú · rol del usuario autenticado. Buscador global · consecutivo, OC del cliente, referencia o NIT. Campana · cuenta solo las novedades que ese usuario puede resolver.
Reto crítico · federar el tenant de Moore para usuarios externos y decidir si el comercial de Puig entra como invitado o usuario local. Es exactamente el modo de falla de Eva: si el acceso cuesta por usuario, el sistema muere. Pend. 14
P-02 Tablero operativo Moore
Analista y líder · pantalla de inicio
Qué hace. Da en una vista el estado de la operación del día con las mismas categorías con las que hoy trabaja Valentina: qué falta subir, qué falta facturar, qué tiene novedad. Las tarjetas son contadores clicables que filtran la tabla.
Componentes. Columna O · semáforo por fila (regla 1.4.1). OC del cliente · lo que la auditoría cruza. Líneas · alerta si supera el límite del documento del cliente. Cita · del operador vía API. Exportar · CSV para el comité.
Retos técnicos. Volumen: Falabella mete 10 a 50 pedidos al día y uno puede traer 212 líneas; paginación y conteos del lado del servidor. Concurrencia: bloqueo optimista con aviso de que otro usuario edita. Refresco sin recargar.
Cambio de comportamiento · hoy el control se lleva rayando a mano el pantallazo de WhatsApp de las 7:30. Aquí el sistema lleva el control: es el punto de gestión del cambio más sensible con el equipo operativo.
P-03 Mis pedidos · vista del comercial
Alejandra y Luciana · alcance por cliente
Qué hace. Le da al comercial visibilidad de sus pedidos sin preguntar por correo, y le concentra en una pestaña lo único que el sistema le pide: aprobar diferencias de precio.
Reglas. El botón de crear pedido es el único punto de entrada del pedido al sistema · la pestaña de aprobación lleva contador, es el trabajo real del comercial · la lista solo muestra sus pedidos o los de sus clientes asignados.
Traducción de vocabulario · EN_APROBACION_DE_PRECIO se muestra como «Requiere tu OK»; ENVIADO_AL_OPERADOR como «En operador». Ningún estado de ERP se filtra a esta pantalla. El comercial no es usuario de sistemas contables: esto no es cosmético, define adopción.
P-04 Crear pedido · paso 1, cabecera
Comercial · Originador POS
Qué hace. Captura la cabecera y, sobre todo, muestra al comercial las reglas que aplican a ese cliente antes de que empiece a pedir. Previene el error en vez de corregirlo: pedagogía preventiva, no texto de ayuda.
NIT 890.900.608-9 Lista: Falabella Operador: Pharex Ventana: 2 días Límite: 250 líneas
Alerta de cartera · al seleccionar el cliente, si está atrasado en pagos el portal lo muestra arriba del formulario y exige un check explícito «Entiendo y continúo con el pedido» para pasar al paso 2. No bloquea: avisa y obliga a verlo, y deja traza en bitácora. Distinto de bloqueado por cartera, que es potestad de Finanzas y sí frena. El dato sale del ERP, de Affinity, no de un reporte manual.
Validaciones. OC obligatoria y única por cliente: previene el escenario de OC duplicada donde el cliente reclamó 20 días después. Sucursal obligatoria si el cliente tiene varias. Dirección no estándar habilitada solo si el parámetro lo permite (hoy solo Market) y genera novedad de verificación.
Retos técnicos. OC duplicada: advertir y exigir confirmación explícita, porque puede haber duplicados legítimos. Datos contaminados: el caso Glam (un cliente compró a otro y las direcciones quedaron cruzadas) obliga a mostrar la fecha de última actualización de cada dirección.
P-05 · la pantalla más importante Líneas y validación
Aquí muere el 60 % del proceso manual
V1La referencia existe y está activa. Si no existe, no se puede agregar: se ofrece solicitar su creación. El comercial nunca crea el producto.
V2El precio es el del catálogo de ese cliente. Si difiere, se marca !DP y se aísla la línea. No se bloquea el pedido.
V3Hay inventario en el operador. Consulta en vivo a Pharex. Si no alcanza, la línea no interrumpe el armado: se aparta y se resuelve en el cierre. Nunca se crea una línea sin respaldo de inventario.
V4La clasificación es la correcta. Vendible y POS no pueden ir en la misma factura: se anuncia en el resumen antes de confirmar, no después.
Componentes con fuente de dato. Buscador · es la entrada principal del pedido, acepta referencia o EAN indistintamente y muestra ambos, con nombre y unidades disponibles. Disponible · inventario del operador, nunca de Affinity. Precio · lista del cliente con margen de volumen aplicado. Resumen · anticipa cuántas remisiones y facturas saldrán.
Cómo se arma el pedido · la barra de búsqueda es la entrada, no el archivo. Para pedidos grandes, Pegar Excel: dos columnas del archivo del cliente, identificador y cantidad, validadas contra Pharex en un solo lote. La OC original se adjunta al expediente sin parsearla. El cierre ocurre en tres canastas: 1 · pedido con inventario, sigue el flujo normal. 2 · pedido en backorder, con tránsito, punto de legalización, ETA y bodega. 3 · ¿te faltó algún producto?, solicitar creación en P-14. Reemplaza a la antigua P-06.
Confirmar · un solo cierre puede generar hasta tres objetos, así que el acuse los nombra en lenguaje del comercial: el pedido con sus líneas y cuántas remisiones y facturas saldrán, el backorder con su número y que Moore ya lo está atendiendo, y cuántas referencias quedaron solicitadas. El resumen advierte antes de confirmar el límite de 250 líneas y que vendible y POS saldrán en facturas separadas. Las diferencias de precio se resuelven en esta misma pantalla: no se le manda un correo a alguien que está sentado frente al pedido. La bandeja P-08 queda para cuando cierra sin resolverlas o la diferencia aparece después. Después de confirmar ya no edita: el cambio pasa por Moore.
Retos técnicos. Latencia: 212 líneas no pueden ser 212 llamadas; consulta por lote o snapshot con hora visible. Precio POS en cero: mostrarlo con la marca (*) y explicarlo. Referencias B: el precio se resuelve desde el PVP. Límite de 250 líneas advertido en el resumen con partido propuesto Pend. 9. Referencia duplicada validada antes de enviar, no tras el rechazo del operador.
P-07 Cola de envío al operador
Analista · mata D1 a D5
Qué hace. Agrupa lo que está listo, corre antes del envío la validación que hoy hace el sistema del operador y devuelve rechazado, y envía en lote.
Integración y degradación. Llama enviar_pedido del adaptador. Si el operador no tiene API, degrada a depositar el archivo en el canal actual más notificación, con marca visible y sin bloquear el flujo.
Retos técnicos. Idempotencia: si el envío falla a mitad de camino, reintentar no puede duplicar el pedido en el sistema del operador. Formato por operador: el adaptador de Pharex produce tipo F para vendibles y R para POS; otro operador tendrá otro layout.
Lo que mata · los pasos D1 a D5: llenar la hoja del operador, guardarla en la ruta, copiarla al FTP y mandar el correo avisando.
P-08 Bandeja de novedades y aprobación de un clic
Comercial ve precio · analista ve todo
Qué hace. Concentra todo lo que está en rojo con el contexto suficiente para decidir sin abrir otra pantalla ni escribir un correo: qué línea, cuánto, desde cuándo y quién responde.
La única decisión humana. Aprobar es un clic, sin cadena de correos. Rechazar quita la línea y devuelve el pedido a borrador. El histórico de precio da el contexto: cuándo cambió y quién lo cambió.
Retos técnicos. Ruteo configurable: precio al comercial de Puig, dirección al analista, error de integración a IT. Escalamiento: si nadie responde, escala al líder; sin esto el pedido se queda en rojo y volvemos al correo. Notificación: el correo es aviso con enlace profundo a la tarjeta. Pend. 15 · definir SLAs
Lo que mata · el paso C7: ante una diferencia de precio, sacar el producto del pedido e informar al cliente por correo esperando respuesta.
P-09 Detalle del pedido y trazabilidad
Todos los roles · sustituye el archivador
Qué hace. Es la ficha completa del pedido y el sustituto del archivador de carpetas por año, mes y consecutivo. Responde la pregunta de auditoría en una pantalla, sin reconstruir nada.
El comercial de Puig no usa esta pantalla · es la ficha de auditoría de Moore, el líder y el auditor. El comercial tiene una vista propia y más simple dentro de P-03, que responde sus tres preguntas —en qué va mi pedido, cuándo llega, qué me falta por hacer— sin trazabilidad técnica, sin documentos contables y sin paquete .zip. Mostrarle esta pantalla lo pondría frente al vocabulario del ERP.
Líneas Documentos Trazabilidad Novedades Posventa Descargar paquete .zip
Componentes. Línea de tiempo · cada hito con fecha, hora y responsable, leída de la bitácora. Líneas · cantidad confirmada frente a solicitada. Documentos · con estado de cada pieza. Trazabilidad · quién cambió qué.
Retos técnicos. Versionado: si el pedido se corrige después de generar la Z hay que conservar ambas versiones; la auditoría puede pedir la que se envió, no la corregida. Integridad: cada documento con hash. Retención: cuánto tiempo se conservan Pend. 16
P-10 Puente con el operador logístico
Analista · reemplaza el pantallazo de las 7:30
Qué hace. Convierte el intercambio por correo, FTP y WhatsApp en estados de sistema, con la salud de la integración a la vista y la diferencia entre lo pedido y lo confirmado explícita.
Retos técnicos. Doble validación manual: hoy hay que verificar que el Excel del operador coincida con el cuerpo del correo. Con API esa doble fuente desaparece; sin API, el sistema compara ambas y levanta novedad ante discrepancia. Timeout: si el operador no responde en el plazo, novedad automática.
Confirmada parcial: el caso normal · generar el documento S renumera la secuencia de 1 en 1, que es exactamente lo que hoy se hace a mano en el paso E19. Lo que está en la Z y no en la S desaparece del documento, pero la secuencia queda continua.
P-11 · restricción comercial más delicada Cola de facturación y ventana de emisión
Mata F1 a F8 y G1 a G25
El algoritmo de la ventana
fecha_emision = fecha_cita − ventana_facturacion_dias(cliente)
Si cae en día no hábil o fin de semana, aplicar regla_dia_no_habil. Falabella: cita lunes → emitir viernes en la franja de hora_limite_emision. Si hay hora límite, programar a esa hora, nunca antes. Si no hay fecha de cita: NO PROGRAMAR y levantar novedad.
Por qué la previsualización es obligatoria. Affinity no permite ver la factura antes de guardarla, ni corregirla ni eliminarla después (A3). El portal arma y muestra la factura completa antes de escribir: si algo está mal, se corrige en el portal, no en el ERP. PwC confirmó una simulación tributaria sin crear pedido ni factura, con IVA, ICA y retención en la fuente y las mismas reglas del cálculo definitivo, siempre que el tercero y los maestros existan en Affinity.
Retos técnicos. Cita reprogramada después de facturar: genera novedad y probablemente nota crédito por fecha. Choque de reglas: Falabella consolida 23 a 24 consecutivos en una factura, pero el documento tiene límite de 250 líneas; hay que definir cuál manda Pend. 6 y 9. Vendible y POS siempre son facturas distintas y solo la vendible se envía al cliente. Idempotencia: clave por pedido y tipo, para que un reintento no genere dos facturas.
Lo que mata · F1 a F8 y G1 a G25: carga manual de Z y S, navegación por menús, diligenciamiento de equipo, comprobante, centro de costos, vendedor, zona, forma de pago y autorretención, y las tres pasadas por corte.
P-12 Posventa · solicitud de nota crédito
Analista solicita · líder aprueba · 12 motivos
Qué hace. Captura la solicitud completa, con líneas y cantidades, aunque el sistema contable todavía no pueda ejecutarla parcialmente. Al elegir el motivo, el sistema explica qué implica: alcance típico, si mueve inventario, si requiere refacturación y el concepto DIAN sugerido.
Reglas. El soporte adjunto es obligatorio en los motivos que lo requieren. El valor se calcula automáticamente desde las líneas seleccionadas. El aviso de limitación es transparencia sobre el estado real de Affinity, no una disculpa.
Retos técnicos. Factura de periodo anterior o de Siigo: no se puede referenciar en Affinity; requiere la ruta de nota crédito de documento, que solo mueve cuentas de ingreso, más un documento adicional de inventario. El portal detecta automáticamente cuál ruta aplica. Mapeo DIAN: si el concepto no es exacto, Affinity no deja referenciar el documento interno. Rebates fuera de alcance Pend. 3
Aviso en pantalla · Affinity hoy no permite notas crédito parciales. La solicitud se registra completa y queda en gestión con protocolo de doble documento. PwC confirmó que el parcial está en el alcance de posventa, con relación a la factura original, control de saldos y mapeo DIAN; cuando se habilite, la ejecución se conecta sin volver a capturar nada.
P-13 Posventa · gestión y ejecución
5 de 7 escenarios son parciales
Por qué importa. Sin esta pantalla, el módulo de posventa no puede construirse hasta que PwC responda. Con ella, se construye hoy y se conecta después.
Protocolo de doble documento · instrucciones generadas
Paso 1 · ruta Cuentas por cobrar › Documentos › Nota crédito. Concepto: devolución de factura de crédito. Mueve solo cuentas de ingreso. marcar hecho
Paso 2 · documento adicional de ajuste de inventario, con referencia, cantidad y bodega. marcar hecho · adjuntar evidencia
Automático vs. manual. Automático: arma el documento, mapea el motivo al concepto DIAN, escribe por API, registra en bitácora y cierra el estado. Manual: los dos pasos en Affinity, cada uno con su casilla, responsable y hora. El caso no cierra hasta que ambas estén marcadas.
Reto principal. Cuando Affinity habilite el parcial, la ejecución debe conectarse sin rediseñar el flujo ni volver a capturar. Por eso el modelo de datos guarda líneas y cantidades desde el día uno. Estado con PwC (8-sep): el parcial está contemplado en posventa, sin fecha. Hoy solo existen J2 y J3, y J3 anula el 100 %.
P-14 Solicitud de creación de referencia
El portal solicita, nunca crea
Qué hace. Convierte en flujo rastreable lo que hoy es un correo suelto, sin romper la separación de funciones. Se abre desde P-05 sin perder el pedido en curso.
SOLICITADA → AUTORIZADA → CREADA_EN_AFFINITY RECHAZADA
Autorización. Go Market no requiere autorización previa. Para los demás clientes se exige el visto bueno adjunto; en los casos que originan Karen o Juliet debe traer el visto bueno de Dolores en la traza del correo. La referencia B se propone según la convención de prefijo y su precio se calcula desde el PVP.
La regla que la sostiene · el portal no crea el producto. La creación ocurre en Affinity por parte de Accounting de Puig. Cuando el sincronizador de catálogo detecta la nueva referencia, cierra la solicitud automáticamente y la línea cae al backorder de esa misma OC. Si esa OC no tenía backorder, se crea en ese momento. El comercial no hace nada: recibe el aviso y la línea ya está en la cola.
Una OC se abre en tres · el pedido con lo que sí se despacha, el backorder con lo que falta, y la solicitud de referencia con lo que ni siquiera existe. Los tres cuelgan de la misma OC, así la pregunta de auditoría se responde en una pantalla. La solicitud no es un pedido: no tiene consecutivo, ni cantidades, ni precio, y su ciclo muere en CREADA_EN_AFFINITY. Al cerrarse, alimenta el backorder, que es la cola única de pendientes de esa OC.
P-15 Backorder
Moore lo gestiona por detrás y notifica
Qué hace. Captura lo que hoy simplemente desaparece del proceso y se gestiona por correo: el faltante que no se despachó y nadie volvió a mirar. Estados logísticos: legalizado, en tránsito, en puerto, con marca de dato no estructurado cuando es captura manual.
Por qué está fuera de la secuencia. Si el faltante se quedara en el pedido original habría que renumerar la secuencia, y eso es reproceso puro. Sacándolo, la secuencia del documento S queda limpia y el backorder se gestiona en su propio ritmo. Convertirlo en pedido genera un pedido nuevo cuando llega el inventario.
P-16 Espejo de maestros
Solo lectura, sin botón de editar
Qué hace. Muestra el estado del espejo y, sobre todo, denuncia los problemas de calidad del dato que hoy están escondidos en los Excel: direcciones sin código de ciudad, referencias sin precio para un cliente, direcciones heredadas de otro NIT.
Productos · 48.221 Precios · 5 listas EAN · 12.043 Clientes · 5 · 214 direcciones Centros · 38
Regla dura · es solo lectura. Si un dato está mal, se corrige en Affinity y se sincroniza. Esto es lo que impide que renazcan las listas paralelas. La depuración inicial de los maestros es un supuesto del proyecto y responsabilidad de Moore.
P-17 · el corazón del multi-cliente Parámetros por cliente
Cada cambio queda en bitácora
Qué hace. Es la pantalla que hace el sistema multi-cliente sin tocar código. Agregar un sexto cliente es llenar esta ficha: ni desarrollo, ni pantallas nuevas. Agrupa identificación, logística, entrada del pedido, facturación, compliance y contable.
Cliente
Entrada
Ventana
Consolida
Autoriza ref.
Falabella
Referencia
2 días
Sí · 23→24
Sí
Go Market
Referencia
Pend.
No
No
Farmatodo
EAN
Pend.
Pend.
Sí
Free
EAN
Pend.
Pend.
Sí
Market
Referencia
Pend.
No
Sí
Market es el único que permite dirección no estándar. Go Market es el único sin autorización previa de referencia y el único con margen de volumen (54 %).
Reto técnico · un cambio de parámetro no puede afectar retroactivamente pedidos ya programados. Los parámetros tienen vigencia y el pedido congela los que le aplicaron al confirmarse. Cambiar una ventana de facturación tiene consecuencias fiscales: todo queda en bitácora.
P-18 Usuarios y roles
IT de Moore · no opera pedidos
Qué hace. El rol determina el menú del servidor. La columna de clientes determina el alcance de los datos: es la única cosa que separa lo que ve Alejandra de lo que ve Luciana.
Decisiones que la bloquean. Pend. 1 · ¿Alejandra y Luciana se reparten clientes o ven todos? Pend. 14 · federación del tenant y política de usuarios externos con IT de Moore: invitado del tenant o usuario local del portal.
La lección de Eva · si el acceso cuesta por usuario, el sistema muere. La política de usuarios externos no es un detalle de IT: es una condición de viabilidad del portal.
P-19 Reportes
Operación y comité · la reportería vive en el portal
Qué responde. Facturado y vendido por día, mes, periodo y YTD. Cumplimiento: pedidos entregados y facturados dentro de la ventana. Reporte diario: automatiza el proceso manual de duplicar el Excel y hacer BUSCARV. Validación cruzada: compara tabla contra movimiento general, igual que hoy se hace a mano. Notas crédito por motivo: permite atacar la causa raíz, no solo procesar.
Reto principal · esto exige lectura de vuelta desde Affinity, no solo escritura. La integración deja de ser unidireccional: es un punto explícito para la mesa técnica con PwC.
P-20 Conciliación de inventario
Rutina semanal, con miras al tiempo real
Qué hace. Reemplaza el cierre mensual manual por una rutina semanal que corre sola y publica las diferencias con su causa probable: backorder abierto, nota crédito ejecutada sin el documento de inventario, o diferencia real.
Fuente estructural de descuadre · las notas crédito de factura externa, que solo mueven cuentas de ingreso, descuadran inventario por diseño. Aquí se hacen visibles.
P-21 Bitácora y paquete de auditoría
Las muestras empiezan en octubre
Qué hace. Es la respuesta directa a lo que la auditoría empieza a pedir en octubre: muestras de remisiones, facturas, la orden de compra original del cliente y, a veces, la confirmación del operador. La auditoría no pide el documento Z.
Regla dura. La bitácora es inmutable, incluso para el administrador. Todo evento de escritura registra usuario, rol, objeto, acción, valor anterior, valor nuevo, marca de tiempo e IP.
Coincidencia de calendario · octubre trae dos cosas al mismo tiempo: la migración de Puig a Affinity y el inicio de las muestras de auditoría. El paquete descargable es lo que evita que ambas se crucen en trabajo manual.
Parte 3 · Reglas

Las reglas de negocio que las pantallas obedecen

33 reglas rastreables al levantamiento. Ninguna vive como texto de ayuda: cada una es una restricción visible en alguna pantalla.

Producto y clasificación
R01–R03 · Cuatro tipos: vendible, POS, PLB y referencia B. Vendible = F2, Z2, S2, tipo F. POS = F4, Z4, S4, tipo R.
R04 · El POS siempre debe tener precio aunque salga en cero: es base gravable de IVA, y el IVA es asumido. P-05
R05 · La factura POS se genera pero no se envía al cliente. P-11
R07 · La referencia B se identifica por prefijo y su precio se calcula desde el PVP. P-14
Precio
R08 · Cada cliente tiene su propia lista de precios. No existe lista única. P-04, P-05
R09 · Go Market maneja margen de volumen, hoy 54 %, variable por negociación. P-17
R10 · Si el precio de la OC difiere del catálogo, se aísla la línea y se escala al comercial. No se bloquea el pedido. P-05, P-08
R11 · Los precios POS salen de la valorización de saldos del mes anterior.
Documento y consecutivo
R14 · Z y S se suben el mismo día. P-10
R15 · Lo que está en la Z y no en la S desaparece, pero la S renumera de 1 en 1. P-10
R16 · Vendibles y POS de una misma OC van siempre en consecutivos y facturas distintas. P-05, P-11
R17 · Una OC con varias direcciones genera una remisión por dirección. P-04
R18–R19 · Falabella consolida 23 a 24 consecutivos; documentos de más de 250 líneas requieren otra vía. Pend. 6 y 9
R20 · El operador rechaza la misma referencia dos veces en un consecutivo. P-07
Facturación y compliance
R22 · La factura se emite máximo dos días antes de la cita. Tres o cuatro días antes, el cliente la rechaza. P-11
R24 · Si la cita cae en lunes, la única negociación es facturar el viernes en la tarde. P-11
R25 · La ventana es configurable por cliente. P-17
R29 · El equipo operativo no puede crear ni parametrizar productos: sería juez y parte. P-14, P-16
R30–R31 · Los POS de Karen o Juliet requieren visto bueno de Dolores; Go Market es el único cliente sin autorización previa. P-14
R32–R33 · La auditoría pide remisión, factura, OC original y a veces la confirmada; no pide la Z. Empieza en octubre. P-21
Parte 4 · Decisiones abiertas

Qué quedó de las decisiones, y qué falta de terceros

Estado al 15 de septiembre: las 28 decisiones tienen respuesta. Lo que queda son tareas de configuración e insumos de terceros; el estado vivo está en la pestaña Decisiones, que lee Jira.

Bloquean construcción
Ninguna. Las definiciones D01 a D28 quedaron cerradas el 15 de septiembre de 2026.
P-08 · KAN-30. Cargar como configuración los SLA acordados con operaciones (D15).
Bloquean parametrización
P-04 · D25. Acordar con PwC cómo se consume el módulo de cartera; Finanzas de Puig define el umbral de mora.
P-21 · D16. Plazos de la política de retención de Moore.
P-16 · D24. Pasar al registro las respuestas de maestros y precios enviadas por correo.
Insumos que necesitamos
Affinity Cloud. Manuales técnicos de las APIs: contratos, ejemplos, códigos funcionales, paginación y límites. Pedidos a PwC el 26 de agosto y el 2 de septiembre.
Pharex. Contratos para inventario, confirmada, cita y POD. Solo existe el de creación de pedidos.
D18. Plan de corte para pedidos y facturas en vuelo el 1 de noviembre.
D11. Aclarar el modelo 040 que aparece en la plantilla de facturas.
Parte 5 · Integraciones

Lo que Affinity y Pharex pueden hacer

Respuestas del equipo técnico de PwC del 8 de septiembre de 2026 a las nueve preguntas de integración, y contrato del servicio web de creación de pedidos de Pharex (APIPED-001). Los manuales técnicos de Affinity Cloud siguen pendientes.

Affinity Cloud · respuestas de PwC
TemaQué confirmó PwCEfecto en el portal
ArquitecturaPuig va sobre Affinity Cloud, por API REST. Sin conexión a Legacy ni a la base de datos.El adaptador se escribe contra servicios REST. Se descarta el escenario del monolito.
Remisión y facturaNo hay webhooks. La trazabilidad documental del pedido (remisiones, facturas, anulaciones, estados e identificadores) se consulta por API.El acuse se obtiene consultando. P-10 y P-11 muestran el pedido en ámbar mientras la consulta no devuelva documentos.
IdempotenciaCada pedido lleva una referencia externa única. Affinity la usa para reconocer reintentos y evitar duplicados.La clave de idempotencia del portal es esa referencia. Reintentar con la misma clave es seguro.
WorkflowEl flujo de Puig se configura por etapas: pedido, remisión y factura. Enviar el pedido no implica facturar de inmediato.La ventana de emisión de P-11 se aplica sobre la factura, no sobre el envío del pedido.
ImpuestosSimulación tributaria sin crear documentos, con IVA, ICA y retención en la fuente, con las mismas reglas del cálculo definitivo. Exige tercero y maestros existentes.La previsualización de P-11 usa ese cálculo. Tercero o maestro faltante se detecta antes de escribir.
ValidacionesEsquema estricto: tercero, inventario, centro y subcentro de costo, proyecto, oficina, moneda y producto rechazan el pedido si fallan. Un servicio caído también impide crearlo.Toda validación es hard-fail. Los códigos funcionales separan error de dato, duplicado y falla temporal: solo la temporal se reintenta.
MaestrosAPIs de productos, inventarios, terceros, precios, centros y subcentros, proyectos, oficinas, bodegas, monedas y tasas, con paginación, filtro por empresa y sincronización incremental.El espejo de maestros (P-16) sincroniza por incremento. Tamaños de página y límites llegan con la documentación.
TercerosCon createThirdParty: false Affinity no crea el tercero y rechaza el pedido con código y mensaje que lo identifican.Coherente con P5: el portal no crea terceros. El rechazo abre novedad con el tercero nombrado.
PosventaLa nota crédito parcial está en el alcance: relación con la factura original, control de cantidades y saldos, límite de líneas y mapeo DIAN.BLOQUEADA_SISTEMA se mantiene como puente y se conecta cuando PwC la habilite, sin recapturar.
Pharex · servicio web de creación de pedidos

Un POST con un JSON que trae la cabecera y la lista lineas_pedidos. Reemplaza el archivo por FTP de la operación enviar_pedido. El pedido de Puig se identifica con CODPED, que hace de clave de idempotencia frente al operador.

CabeceraDescripciónTipoObligatorio
CODPEDCódigo de pedidoC(20)Sí
SUPEDIDOPedido interno del clienteC(20)Sí
CODCLICódigo del destinatarioC(20)Sí
NITNIT del destinatarioC(20)Sí
DESCLINombre del destinatarioC(40)Sí
POBLACIONCiudad de destinoC(20)Sí
DIRECCIONDirección de destinoC(60)Sí
TELEFONOTeléfono del destinatarioC(20)No
FECHA_ENTREGAFecha estimada de entrega o citaC(10)No
FECHA_PEDIDOFecha de generaciónC(10)Sí
VALOR_ASEGURADOValor de seguroINTSí
OBSERVACIONDetalle adicionalC(60)No
CLIENTE · USUARIO · CLAVECredenciales de acceso que entrega PharexC(4) · C(20)Sí
LíneasDescripciónTipoObligatorio
CODARTCódigo del artículoC(20)Sí
DESARTDescripción del artículoCNo
CANTIDADUnidades—Sí, en el ejemplo
CODLOT · CADUCI · DIAS_CADUCIDADLote, caducidad y díasC(20) · INTNo
ACON · DESCRIPCION_ACONRequiere acondicionamiento (S/N) y detalleC(1) · C(60)Sí · No
VALOR_UNITARIOValor unitarioFLOATNo
200Transferencia exitosa. El pedido queda en el operador.
400Campo vacío o más largo de lo permitido. Error de dato: novedad al analista, no se reintenta.
401Usuario o clave inválidos. Error de integración: escala a IT.
409El código de pedido ya existe. Duplicado: se trata como ya enviado y se verifica, no se reenvía.
LO QUE FALTA DE PHAREX
El documento solo cubre la creación del pedido. No hay contrato para consultar inventario, recibir la confirmada, la cita de entrega ni el POD: esas operaciones siguen en su modo degradado. El documento tiene inconsistencias por aclarar: CANTIDAD aparece en el ejemplo pero no en la tabla, ACON está repetido y la descripción de DESART no corresponde. La URL publicada es http y las credenciales viajan en el cuerpo: se revisa contra la política AD-PL-11 de Moore antes de producción.
Matriz de clientes y confirmaciones
Moore compartió la matriz de 20 clientes y canales (Falabella .COM y tiendas, Go Market, Farmatodo, Dufry, Arle, Faces, Glam, Fruta Fresca, Medipiel, Éxito, Rappi, entre otros) y ejemplos reales de la hoja de confirmación por cliente. De ahí salen las fichas de P-17 y las reglas obligatorias para todos los pedidos: código DANE obligatorio, consecutivo único sin duplicar, el NIT no se arrastra entre filas, y la separación comercial frente a POS en venta y obsequio (F frente a R). Falabella exige además número y nombre de tienda, cita confirmada y OC abierta antes de facturar, con un máximo de 72 horas.
El pedido no se corrige: nace bien o no nace.
Las 36 pantallas existen para que ninguna de las 99 actividades del proceso actual tenga que seguir existiendo. Lo que el sistema no pueda ejecutar, lo muestra: degrada con marca visible, nunca bloquea.
Siguiente paso
Congelar el alcance con el demo v2 y arrancar la construcción: las 28 decisiones están cerradas.
Insumo crítico
Manuales técnicos de Affinity Cloud y contratos de Pharex para inventario, confirmada y cita.
Fecha que manda
Octubre: primeras muestras de auditoría. 1 de noviembre: Puig en Affinity Cloud.
05 · Decisiones abiertas

0 decisiones abiertas

Cada una depende de una respuesta de Moore, Puig, PwC o Pharex. Mientras esté abierta, la pantalla que gobierna queda marcada como dependiente. Despliega cada fila para ver la respuesta y su efecto en el portal.

4
Bloquean construcción
6
Esperan insumo de Moore
2
Dependen de Pharex
7
Pantallas afectadas
ID
Decisión
Afecta
Responde
Estado
06 · Reglas

Principios, restricciones y permisos

Siete principios de diseño, las siete restricciones duras de Affinity con lo que PwC confirmó en septiembre, y la matriz de permisos de los ocho perfiles. Nada del portal existe sin una de estas reglas detrás.

P1
El error se mata en el origen
El 60 % de las 99 actividades existe porque el pedido nace desestructurado. No se automatizan: dejan de tener razón de ser.
P2
Una fuente de verdad por dato
Affinity manda sobre SKU y precio. El operador sobre inventario. El portal sobre el flujo. Cero Excel paralelos.
P3
El correo deja de ser el canal
Correo, WhatsApp y FTP quedan como notificación. El estado vive en el portal y es el mismo para las dos partes.
P4
Una sola decisión humana
La aprobación de una diferencia de precio. Todo lo demás es validación automática o generación determinística.
P5
Separación de funciones
Quien crea el pedido no crea el producto ni fija el precio. El portal solicita, nunca crea: “serían juez y parte”.
P6
Cada pedido arma su auditoría
OC, Z, S, hoja del operador, remisión, factura y POD atados al pedido. La muestra de octubre sale con un clic.
P7
Se diseña contra Affinity
Puig migra a Affinity Cloud el 1 de noviembre. Siigo se soporta solo como modo de transición, con fecha de caducidad explícita.
LECCIÓN DE EVA
Nada bloquea el flujo
Toda capacidad faltante degrada a captura manual con marca visible. Es la lección directa del fracaso anterior.

Restricciones duras de Affinity

A1Secuencia estricta de documentos: pedido → remisión → factura. Para Puig el flujo se configura por etapas: enviar el pedido no obliga a facturar de inmediato.
A2Autorización agrupada: no se autoriza documento por documento.
A3Affinity no previsualiza la factura: la previsualización la construye el portal antes de escribir, con la simulación tributaria que PwC confirmó.
A4Nota crédito solo al 100 %: las parciales se ejecutan con el protocolo de doble documento hasta que PwC habilite el parcial, ya incluido en su alcance de posventa.
A5La nota crédito externa no mueve inventario: requiere documento de devolución aparte.
A6Concepto DIAN exacto: el motivo de la nota crédito se mapea a un concepto cerrado.
A7Doble plantilla de carga: el mapeo de la OC cambia según el cliente.

Matriz de permisos

Objeto
Comercial
Orig. POS
Finanzas Puig
Analista
Líder
Admin
Auditor
Dirección
Pedido propio
Crea y edita en preparación
Crea pedidos POS
Consulta
Ve todos, edita y anula
Igual que el analista
No opera pedidos
Consulta
Consulta agregada
Aprobación de precio
Aprueba la de su cartera
No
No
Escala, no aprueba
Aprueba en ausencia
No
Consulta
No
Backorder
Crea
No · genera novedad al analista
No
Atiende y convierte
Atiende y convierte
No
Consulta
Consulta
Solicitud de referencia
Crea
Crea
No
Crea
Crea y hace seguimiento
No
Consulta
No
Envío al operador
No
No
No
Sí
Sí
No
No
No
Disparo de facturación
No
No
No
Sí
Sí
No
No
No
Nota crédito
Solicita en lenguaje comercial
No
Aprueba la etapa Puig
Solicita y gestiona
Aprueba la etapa Moore
No
Consulta
Consulta
Bloqueo por cartera
Reconoce y continúa
No
Libera
Consulta
Consulta
No
Consulta
Consulta
Parámetros de cliente
No
No
No
Consulta
Edita
Edita
Consulta
Consulta
Usuarios y roles
No
No
No
No
No
Edita
Consulta
No
Espejo de maestros
No
No
No
Consulta y empareja
Consulta y empareja
Edita
Consulta
No
Bitácora
Sus eventos
Sus eventos
Sus eventos
Todos
Todos
Todos, sin editar
Todos
Sin acceso
Paquete de auditoría
No
No
No
Genera
Genera
Genera
Genera y descarga
No
Reportes
Los suyos
No
Financieros
Operativos
Operativos y de equipo
Técnicos
De auditoría
Todos, agregados
07 · Jira en vivo

Estado del tablero

Lectura directa del tablero del proyecto. Este panel no es un reporte que alguien escribe: es el mismo dato que ve el equipo, con la hora del último sincronismo.

Sin sincronizar Proyecto KAN
Clave
Tarea
Responsable
Estado
08 · Diseño del portal

Demo navegable v2

El diseño aprobado del portal, funcionando. Elige un perfil para entrar: cada uno tiene su propio menú. Los datos son de trabajo, la autenticación es simulada y el simulador de sistemas externos (N-16) provoca las respuestas de Affinity y Pharex.

Abrir en otra pestaña ↗
Diseño del portal · demo navegable v2
Diseño aprobado · 36 pantallas · 8 perfiles · se carga al abrir esta pestaña
LIFE·IN·CO
Portal de Pedidos y Facturación · Puig Fase 1 · Diseño cerrado · corte 15 sep 2026 LIFE·IN·CO