Appearance
M03 B2B -- Requerimientos
| Campo | Valor |
|---|---|
| Estado | Borrador |
| Prioridad | Fase 1 |
| Última actualización | 2026-03-25 |
| Reuniones vinculadas | 2026-03-05, 2026-03-09, 2026-03-10-p2, 2026-03-24 |
1. Objetivo
Gestionar de punta a punta la operación entre clientes con convenio (farmacias, clínicas, hospitales) y el recetario: carga de solicitudes, validación, seguimiento, incidencias y traspaso a producción. El módulo debe ser útil tanto para las ejecutivas del recetario como para los clientes no técnicos que operan los convenios.
2. Alcance
2.1 Sí pertenece a B2B
- Gestión de convenios por cliente.
- Ingreso de solicitudes por canal convenio (manual, masivo, API).
- Validación operativa y comercial de solicitudes.
- Trazabilidad de estados para el cliente convenio.
- Gestión de incidencias y tickets.
- API para carga y consulta de solicitudes.
- Carga masiva de recetas y documentos (Excel, CSV, archivos por carpeta).
- Notificaciones por eventos relevantes.
- Reportes operativos y comerciales.
2.2 No pertenece a B2B
- Cálculo puro de cotización o precio unitario --> M02 Cotización.
- Cálculo estructural de costos --> M06 Costeo.
- Ejecución productiva detallada (lotes, avance interno técnico) --> M04 Producción.
- Canal abierto sin convenio --> M05 Marketplace.
3. Actores
| Actor | Descripción | Capacidades principales |
|---|---|---|
| Farmacia/cliente con convenio | Farmacia de retail, clínica u hospital que tiene un convenio vigente con el recetario | Cargar solicitudes y recetas (manual o masivo), consultar estado por solicitud, ver observaciones pendientes, recibir confirmaciones y alertas, consultar historial por período |
| Recetario -- operación comercial | Equipo comercial del recetario que administra la relación con los clientes convenio | Crear y administrar convenios, definir condiciones por cliente (vigencia, reglas, precios enlazados), mantener trazabilidad de cambios por convenio |
| Recetario -- operación diaria | Ejecutivas del recetario que gestionan el día a día de las solicitudes | Recibir solicitudes (manual, API, masivo), validar receta y datos requeridos, marcar observaciones y pedir correcciones, confirmar solicitudes válidas, derivar a producción, mantener visibilidad de avance al cliente |
4. Flujo principal
Origen: Documento original M03 B2B, reuniones 2026-03-05 y 2026-03-10-p2.
5. Funcionalidades detalladas
F-M03-001: Gestión de convenios
Descripción: Crear, editar y desactivar convenios entre el recetario y sus clientes. Cada convenio define las condiciones comerciales, la vigencia y las reglas de operación.
Detalle:
- Alta de convenio con datos del cliente (razón social, RUT, contactos, sucursales).
- Configuración de condiciones: vigencia, descuentos pactados, precios enlazados desde M06 Costeo.
- Historial de cambios por convenio (quién modificó, cuándo, qué cambió).
- Estado del convenio: Activo, Suspendido, Finalizado.
- Un recetario puede tener N convenios; una farmacia puede tener convenios con N recetarios.
Origen: Reuniones 2026-03-05 (Inger: "la gestión de los convenios"), 2026-03-10-p2 (Farmacéutica Reccius: "la relación con Santa Gemita se canalice a través de tu magistral").
F-M03-002: Ingreso de solicitudes (manual)
Descripción: Formulario para que el cliente convenio cargue una solicitud individual.
Detalle:
- Campos mínimos: identificador de cliente convenio, producto o referencia de preparación, cantidad, datos de receta/documento, observaciones.
- Validaciones mínimas al guardar (campos obligatorios, formato).
- Confirmación inmediata de recepción con número de solicitud.
Origen: Documento original M03 B2B, sección "Carga manual".
F-M03-003: Carga masiva de recetas (Excel/CSV/documentos)
Descripción: Permitir al cliente convenio cargar múltiples recetas en un solo lote, ya sea mediante archivo estructurado (Excel/CSV) o mediante carga de documentos organizados por carpeta.
Detalle:
- Carga de archivo Excel o CSV con múltiples líneas de solicitud.
- Carga de documentos (imágenes de recetas, PDFs) organizados por carpeta con estructura de fecha (ejemplo: carpeta "recetas-260305" para recetas del 5 de marzo de 2026).
- Resultado de carga: registros correctos vs. registros con error.
- Reintento de registros fallidos sin reprocesar los exitosos.
- Historial de lotes cargados con fecha, cantidad y resultado.
- Notificación al recetario: "El cliente [nombre] ha cargado recetas para el día [fecha]".
Nota específica -- caso Santa Gemita/Salco: En la reunión del 10 de marzo (p2), se discutió que Santa Gemita carga recetas mediante carpetas con archivos organizados por fecha. El sistema debe soportar esta modalidad, permitiendo que el cliente suba una carpeta por día con N documentos de receta, conservando la estructura de carpetas como referencia de trazabilidad. Salco trabaja actualmente con un Excel básico (número de contraseña, producto, cantidad, estado R/P) que también debe ser soportado.
Origen: Documento original M03 B2B, sección "Carga masiva". Reunión 2026-03-05 (Inger: "la carga masiva de documentos... que se creará una carpeta por día"). Reunión 2026-03-10-p2 (discusión Santa Gemita).
F-M03-004: API para inyección y consulta
Descripción: Endpoints REST para que sistemas externos inyecten solicitudes y consulten estados de forma programática.
Detalle:
- Endpoint para inyectar solicitudes (POST) con los mismos campos que la carga manual.
- Endpoint para consultar estado de una solicitud por identificador (GET).
- Endpoint para consultar lote completo de solicitudes por período o por lote (GET).
- Trazabilidad por identificador externo del cliente (el cliente puede consultar con su propio código).
- Autenticación por API key vinculada al convenio.
Origen: Documento original M03 B2B, sección "API". Reunión 2026-03-05 (Felipe: "disponibilizar una API para que las distintas farmacias logren consultar e inyectar solicitudes").
F-M03-005: Validación operativa y comercial
Descripción: Proceso mediante el cual la ejecutiva del recetario valida que la solicitud tiene toda la información necesaria y cumple las condiciones del convenio.
Detalle:
- Validación de datos obligatorios: receta legible, datos del paciente, datos del médico, producto identificable.
- Validación comercial: el producto solicitado está dentro de las condiciones del convenio, el convenio está vigente.
- Posibilidad de validación asistida por IA: el sistema pre-procesa la receta, identifica el producto y presenta un resumen para que la ejecutiva confirme o corrija.
- Si falta información: marcar como Observado con detalle del faltante, notificar al cliente.
- Si la información es completa: pasar a cotización/aprobación según regla.
Origen: Documento original M03 B2B, flujo operativo. Reunión 2026-03-05 (Felipe: "generar un flujo automatizado y que una IA haga esta validación"; Inger: "al menos si lo va a ingresar una IA que lo va a revisar un humano").
F-M03-006: Trazabilidad de estados
Descripción: Cada solicitud B2B transita por un conjunto definido de estados que son visibles para el cliente convenio.
Diagrama de estados:
Detalle:
- Cada cambio de estado queda registrado con timestamp, actor y observación.
- B2B muestra estos estados al cliente; el detalle técnico interno de producción vive en M04 Producción.
- El cliente puede filtrar solicitudes por estado para gestionar su operación diaria.
Origen: Documento original M03 B2B, sección "Estados mínimos B2B". Reunión 2026-03-05 (Inger: "que ellos coloquen cuando lo vayan a recepcionando... recepcionada, pendiente").
F-M03-007: Gestión de incidencias/tickets
Descripción: Sistema de tickets para registrar y resolver incidencias asociadas a solicitudes B2B.
Detalle:
- Crear ticket vinculado a una solicitud específica.
- Clasificación de incidencia: dato faltante, receta ilegible, error de carga, retraso en producción, problema de despacho, otro.
- Asignación de responsable.
- Registro de resolución con fecha y detalle.
- Historial completo de la incidencia.
Origen: Documento original M03 B2B, sección "Gestión de incidencias".
F-M03-008: Notificaciones por eventos
Descripción: Notificaciones automáticas ante eventos relevantes del ciclo de vida de las solicitudes.
Eventos notificables (mínimo viable):
| Evento | Destinatario | Canal sugerido |
|---|---|---|
| Nueva carga recibida | Recetario (ejecutiva) | Email, plataforma |
| Carga con errores | Cliente convenio | Email, plataforma |
| Solicitud observada | Cliente convenio | Email, plataforma |
| Solicitud derivada a producción | Cliente convenio, Recetario | Email, plataforma |
| Cambio relevante de estado | Cliente convenio | Email, plataforma, WhatsApp |
| Solicitud despachada | Cliente convenio | Email, WhatsApp |
Origen: Documento original M03 B2B, sección "Notificaciones". Reunión 2026-03-05 (Inger: "a mí como recetario que me va a salir un mensaje diciendo el cliente Salco Brand ha cargado recetas para el día de hoy").
F-M03-009: Reportes operativos y comerciales
Descripción: Reportes mínimos para medir el desempeño del canal B2B.
Reportes:
- Volumen por cliente convenio (solicitudes por período).
- Porcentaje de solicitudes observadas vs. total.
- Tiempo de validación (desde carga hasta validado).
- Tiempo de ciclo completo (desde carga hasta entrega).
- Incidencias por tipo y por cliente.
- Comparación de volumen y precio entre convenios (uso interno del recetario).
Origen: Documento original M03 B2B, sección "Reportes mínimos". Reunión 2026-03-05 (Inger: "me interesa saber si a farmacia A le vendo tanto, a farmacia B le vendo tanto").
6. Datos mínimos por solicitud B2B
| Campo | Tipo | Obligatorio | Descripción |
|---|---|---|---|
| id_solicitud | UUID | Sí | Identificador único generado por el sistema |
| id_convenio | UUID | Sí | Convenio al que pertenece la solicitud |
| id_cliente | UUID | Sí | Cliente convenio que carga la solicitud |
| id_externo | Texto | No | Identificador propio del cliente (para trazabilidad cruzada) |
| producto_referencia | Texto | Sí | Nombre o código del producto/preparación solicitada |
| cantidad | Numérico | Sí | Cantidad solicitada (unidades, gramos, ml según tipo) |
| datos_receta | Texto/Archivo | Sí | Datos mínimos de la receta o documento adjunto |
| fecha_carga | Timestamp | Sí | Fecha y hora de carga |
| estado_actual | Enum | Sí | Estado vigente de la solicitud |
| observaciones | Texto | No | Observaciones o incidencias asociadas |
7. Reglas de negocio
| ID | Regla | Origen |
|---|---|---|
| R-M03-001 | B2B y Marketplace son canales distintos. Una farmacia con convenio opera por B2B; sin convenio, por Marketplace. | Reunión 2026-03-05 |
| R-M03-002 | Carga masiva y API son canales de entrada obligatorios por la realidad operativa de los clientes. | Reunión 2026-03-05 |
| R-M03-003 | B2B debe ser útil para ejecutivas y clientes no técnicos. La interfaz debe ser simple y orientada a tareas. | Reunión 2026-03-05 |
| R-M03-004 | B2B concentra la operación de seguimiento de convenios. La cotización de convenio puede partir simple pero el seguimiento es responsabilidad de este módulo. | Reunión 2026-03-05 |
| R-M03-005 | La carga de recetas por carpetas organizadas por fecha debe ser soportada (caso Santa Gemita). | Reunión 2026-03-10-p2 |
| R-M03-006 | El precio que ve el cliente convenio es el precio que el recetario le asignó por convenio. El cliente no debe ver la tabla de precios general del recetario. | Reunión 2026-03-10-p2 (Inger: "no les puse mi precio... uno no quiere que manejen esa información") |
| R-M03-007 | El cliente convenio puede aplicar su propio factor de margen sobre el precio de convenio para calcular su precio de venta al público. Esto es información interna del cliente. | Reuniones 2026-03-05, 2026-03-24 |
| R-M03-008 | Los estados que B2B muestra al cliente son estados de cara al convenio. El detalle técnico de producción vive en M04. | Documento original M03 B2B |
| R-M03-009 | No se debe generar ruido al canal: el recetario no compite con sus propios clientes convenio. Los precios de convenio no son públicos. | Reunión 2026-03-10-p2 (Farmacéutica Reccius: "yo no puedo ir a competir con mi canal") |
8. Dependencias
| Dependencia | Dirección | Detalle |
|---|---|---|
| M06 Costeo --> M03 B2B | Entrada | M06 provee el precio base por fórmula que B2B consume para armar el precio de convenio |
| M02 Cotización --> M03 B2B | Entrada | Una cotización confirmada puede generar una solicitud B2B si el cliente tiene convenio |
| M03 B2B --> M04 Producción | Salida | La solicitud aprobada se deriva como orden de trabajo a Producción |
9. Pantallas del cliente convenio (visión mínima)
Lo que el cliente convenio necesita ver en su portal:
- Resumen de cargas del día.
- Solicitudes con estado actual (filtrable por estado).
- Solicitudes con error u observación (destacadas).
- Fecha estimada de entrega (cuando aplique).
- Canal de soporte/ticket para incidencias.
- Historial por período.
Lo que el cliente convenio NO debería hacer en MVP:
- Ajustar lógica interna del recetario.
- Resolver excepciones clínicas complejas.
- Operar estados técnicos de producción.
10. Pendientes de cierre
| Pendiente | Estado | Notas |
|---|---|---|
| Reglas exactas de aprobación automática vs. manual | Abierto | Definir umbrales por convenio |
| SLA por cliente convenio | Abierto | Definir tiempos comprometidos por tipo de producto |
| Matriz de permisos por rol (ejecutiva, supervisión, comercial) | Abierto | Definir qué puede hacer cada rol dentro del recetario |
| Formato estándar de archivos para carga masiva | Abierto | Definir plantilla Excel/CSV oficial |
| Política de re-proceso de solicitudes rechazadas/observadas | Abierto | Definir cuántos reintentos y plazos |
11. Historial de cambios
| Fecha | Reunión | Cambio |
|---|---|---|
| 2026-03-05 | 2026-03-05 | Definición inicial del módulo B2B, canales de entrada, caso Salco/Santa Gemita |
| 2026-03-09 | 2026-03-09 | Separación de fronteras: B2B vs. Cotización vs. Marketplace |
| 2026-03-10 | 2026-03-10-p2 | Detalle del flujo con Santa Gemita, carga por carpetas, protección de precios de convenio |
| 2026-03-24 | 2026-03-24 | Confirmación de que B2B es Fase 1, refinamiento de requerimientos del cotizador de convenio |
| 2026-03-25 | -- | Creación del documento de requerimientos completo |
Volver al Índice general | Ver Arquitectura modular | Ver Historias de usuario M03 | Ver Modelo de datos M03