Plataforma de Automatización Financiera

Esta propuesta plantea una primera etapa enfocada: una plataforma web que centraliza la facturación y las cuentas por cobrar sobre BIND ERP, el sistema ya confirmado como fuente de verdad. El MVP permite emitir facturas en MXN y USD desde la plataforma —creando la cotización y convirtiéndola en factura a través de la API de BIND, que conserva el timbrado CFDI— y entrega además visibilidad, dashboard, alertas y reglas de cobranza. Toda emisión opera con confirmación humana y modo de simulación, de modo que la prioridad #1 de Balam (facturación) se atiende sin asumir riesgos fiscales. Con el ajuste de julio de 2026, el alcance incorpora además la integración con Jira: los tickets de la bandeja de Facturación generan automáticamente su cotización en BIND, conservando los mismos candados de control. La arquitectura queda preparada para incorporar conciliación bancaria, pagos en línea, contabilidad e integraciones adicionales conforme se validen.

En síntesis

El enfoque responde directamente a la indicación del CTO de priorizar facturación y BIND en esta primera fase, evitando comprometer alcance que dependa de integraciones aún no disponibles o no prioritarias. La integración con Jira —originalmente diferida— se incorporó en julio de 2026 como ajuste de alcance, una vez que la propia dirección confirmó que el proceso de facturación se gobierna en Jira y que su API cubre lo necesario.

1.1El problema

Durante la sesión con el equipo directivo, la lectura del requerimiento fue clara: "El proceso está tan desvinculado… pasa por varias manos… cada parte humana se está equivocando." El reto no es de naturaleza técnica, sino operativa y económica. Cada traspaso manual entre nómina, facturación, cobranza, conciliación y contabilidad genera errores que se traducen en dinero perdido, retrabajo y deterioro en la relación con clientes clave.

1.2Contexto que define el alcance

Tras la sesión de seguimiento y las actualizaciones del CTO del 25 de mayo, cuatro factores reordenan el alcance del MVP:

1. BIND ERP cuenta con API oficial (api.bind.com.mx, OData v3, 20,000 solicitudes/día). Esto permite una integración por API en tiempo cercano a real, superando el supuesto inicial de exportación manual de archivos.
2. La dirección técnica priorizó la facturación. Conforme a la indicación de considerar "únicamente BIND ERP en una primera etapa", funcionalidades como pagos en línea, conciliación bancaria, recordatorios automáticos a clientes y asientos contables se difieren de manera explícita a fases posteriores.
3. BUK dispone de API, confirmada por el equipo de Balam, aunque no constituye una prioridad inmediata. Queda contemplada en el roadmap sin condicionar el MVP.
4. El proceso interno evolucionó hacia Jira (confirmado por la dirección en julio de 2026): hoy todo el flujo de facturación nace y se gobierna en Jira — "lo que no está en Jira no se procesa" — con una bandeja dedicada (Facturación, llave FAC-) y un flujo de estatus formal. Por ello, la integración con Jira se incorporó al alcance como ajuste conforme al control de cambios (§10), detallado en la §2.

1.3Sistemas actuales

1.4Solución propuesta

Se propone una capa de operaciones financieras sobre BIND ERP, no un reemplazo. BIND conserva su rol como fuente de verdad para facturación, timbrado CFDI y contabilidad; la plataforma orquesta la visibilidad, las reglas de cobranza, el tablero directivo y la trazabilidad que hoy no existen de forma centralizada.

Alcance funcional del MVP:

• Integración con BIND ERP vía API: lectura primero y escritura asistida una vez validada en Discovery.
• Integración con Jira (ajuste jul-2026): lectura de los tickets de la bandeja Facturación (FAC-) y generación automática de la cotización en BIND al alcanzar el estatus disparador que Balam defina, mediante la misma capa de escritura controlada y con trazabilidad ticket ↔ cotización ↔ factura.
• Emisión de facturas desde la plataforma: creación de cotización y conversión a factura en MXN (con IVA) y USD (sin IVA, para clientes extranjeros) a través de la API de BIND, con timbrado a cargo del PAC de BIND, confirmación humana obligatoria y modo de simulación (dry-run) previo a cada emisión.
• Catálogo central de clientes con lista blanca configurable (ACUNTIA + Top 3).
• Vista unificada de facturación: estados, vencimientos, filtros y descarga de PDF/XML.
• Cobranza operativa: antigüedad de cartera (aging) y alertas internas para el equipo de Finanzas.
• Tablero financiero con indicadores de cuentas por cobrar, vencidas y próximas a vencer.
• Reportes exportables en CSV/XLSX.
• Operación multimoneda MXN y USD, con tipo de cambio del DOF capturado al momento de la facturación.
• Autenticación y control de acceso por roles (Finanzas, Dirección, Operaciones, Administración).
• Arquitectura preparada para multi-tenant y bitácora de auditoría universal.

Visión integral (fases posteriores, cotizadas en el Anexo B):

La arquitectura del MVP se diseña para cerrar progresivamente el ciclo financiero descrito por la dirección:

La incorporación posterior de pagos en línea, recordatorios automáticos, conciliación bancaria, asientos contables o BUK se realiza sobre la misma base, sin reescribir lo construido.

1.5Criterios de éxito de la primera etapa

• Emisión de facturas en MXN y USD desde la plataforma, con confirmación humana y sin incidentes fiscales.
• Visibilidad en tiempo cercano a real del estado de facturación y cuentas por cobrar, para Dirección y Finanzas.
• Reducción medible del trabajo manual de consulta y reporteo sobre BIND.
• Aplicación correcta de la lista blanca: ACUNTIA y Top 3 nunca reciben recordatorios automáticos masivos.
• Entrega del MVP funcional en el plazo comprometido, con alcance acotado y sin desviaciones.
• Trazabilidad ticket de Jira → cotización → factura sin captura manual duplicada, una vez definido el flujo de facturación.
• Control fiscal: ninguna factura se emite sin confirmación humana explícita; el timbrado CFDI permanece a cargo del PAC de BIND.

1.6Escala operativa de referencia

• 45 colaboradores en nómina y 5 freelancers.
• Aproximadamente 50 facturas emitidas al mes.
• 3 instituciones bancarias (2 México + IBC Bank Texas) — fuera de esta etapa.
• 2 jurisdicciones fiscales (México y Texas, impuestos estándar en el MVP).
• Interlocutores operativos: Pedro (contacto técnico) y gerencia administrativa, con supervisión ejecutiva de Noe (CTO), Araceli (CEO) y Erika (PM).

Stack tecnológico propuesto

La selección tecnológica privilegia robustez empresarial, mantenibilidad a largo plazo y afinidad con Azure. El binomio .NET + Azure es una combinación nativa de Microsoft, lo que reduce fricción de despliegue, seguridad y operación para una aplicación financiera.

El proyecto se organiza en cuatro etapas secuenciales, más el ajuste Jira → BIND incorporado en julio de 2026 (al final de esta sección). Cada bloque concluye con un entregable demostrable y se factura conforme a horas reales (ver §3).

Objetivo. Validar el comportamiento real de la API de BIND con la cuenta de Balam, preparar la infraestructura en Azure, dejar el repositorio operativo y entregar un prototipo visual navegable que alinee expectativas de producto antes de iniciar el desarrollo del backend.

• Validación de la API de BIND con cuenta real: recursos Invoices, Payments, Customers, Products y Activities; confirmación de los campos saldo, vencimiento y estado, y del comportamiento de paginación OData.
• Confirmación de los límites de uso (20,000 solicitudes/día) y definición de la estrategia de consumo.
• Infraestructura base en Azure: App Service, PostgreSQL Flexible, Storage, Key Vault y Application Insights; ambiente de staging preparado.
• Repositorio monorepo con CI/CD, gestión de secretos y guardrails de seguridad del flujo de trabajo asistido por IA.
• Documento de hallazgos, decisiones de arquitectura (ADRs) iniciales y plan refinado de las etapas siguientes.
• Prototipo visual navegable (con la identidad del manual de marca aplicada) de las 5–6 pantallas principales: inicio de sesión, tablero financiero, listado de facturas, detalle de factura, catálogo de clientes con lista blanca y configuración de alertas. Con datos de ejemplo y navegación real, para validar las decisiones de experiencia con Pedro y Araceli antes de construir.

Objetivo. Plataforma funcional que ingiere clientes y facturas de BIND vía API, los normaliza, mantiene su trazabilidad y habilita la capa de escritura controlada.

• Backend con autenticación, control de acceso por roles (Finanzas, Dirección, Operaciones, Administración) y bitácora de auditoría universal.
• Arquitectura multi-tenant a nivel de esquema (tenant_id + RLS), sin alta autoservicio.
• Cliente de la API de BIND con doble encabezado de autenticación, reintentos con backoff, manejo de límites de uso, constructor de consultas OData y mapeo de errores.
• Capa de escritura controlada: operaciones de creación de cotización y conversión a factura, envueltas en un mecanismo de simulación (dry-run), confirmación y feature flag, con registro en bitácora de toda llamada de escritura.
• Sincronización programada de clientes (normalización y deduplicación).
• Sincronización programada de facturas y cotizaciones (estado normalizado, captura de tipo de cambio y manejo de paginación OData).
• Modelo central de facturas con estados (Emitida, Vigente, Vencida, Pagada, Cancelada).
• Migraciones versionadas y datos de prueba.

Objetivo. Llevar a producción la interfaz validada en el prototipo, conectada al backend real, habilitando tanto la consulta como la emisión asistida de facturas en MXN y USD, con catálogo de clientes y soporte multimoneda.

• Implementación productiva de las pantallas validadas (componentes de Angular Material con la identidad ya aplicada en la Etapa 0).
• Integración del frontend con el backend (autenticación, ruteo, gestión de estado y caché).
• Listado de facturas con filtros (cliente, moneda, fecha, vencimiento, estatus), búsqueda, paginación y ordenamiento.
• Detalle de factura con descarga de PDF/XML desde BIND.
• Creación de cotizaciones desde la plataforma y conversión a factura vía API de BIND.
• Emisión multimoneda: MXN con IVA y USD sin IVA para clientes extranjeros, conforme a las reglas fiscales aplicables.
• Flujo de emisión con confirmación humana obligatoria y modo de simulación (dry-run): ninguna factura se emite sin aprobación explícita; toda operación de escritura queda registrada en bitácora.
• Catálogo de clientes con la bandera de lista blanca configurable (ACUNTIA + Top 3), editable por el rol de Administración.
• Tipo de cambio del DOF (proceso programado y captura al momento de la facturación) para la conversión MXN ↔ USD.
• Exportación de facturas y clientes a CSV/XLSX.
• Manual de usuario para los equipos de Finanzas y Dirección.

Objetivo. Cerrar el flujo operativo con visibilidad para Dirección y realizar la entrega formal.

• Módulo de cobranza: antigüedad de cartera (30/60/90 días) y vistas de facturas por vencer y vencidas.
• Alertas internas configurables para Finanzas (5 días antes del vencimiento, facturas vencidas y registros con datos faltantes).
• Aplicación de la lista blanca: ACUNTIA y Top 3 nunca generan alertas automáticas de envío masivo.
• Tablero directivo con indicadores de cuentas por cobrar totales y por cliente, vencidas, próximas a vencer, monto pendiente por cliente y estado de alertas.
• Reporte operativo configurable (frecuencia, destinatarios y formato CSV/XLSX/PDF).
• Endurecimiento de seguridad y revisión de secretos.
• Respaldos automáticos y plan de recuperación documentado.
• Documentación técnica: README, runbook operativo y ADRs.
• Sesión de capacitación grabada (1.5–2 h) con Pedro y la gerencia administrativa.
• Transferencia y soporte posterior al lanzamiento de 2 semanas (corrección de defectos).

Antecedente. La versión anterior de esta propuesta dejó Jira fuera del alcance conforme a la información disponible al cotizar. En las sesiones del 22, 24 y 27 de julio la dirección confirmó que el proceso interno evolucionó — todo el flujo de facturación nace y se gobierna en Jira — y quedó confirmada la viabilidad técnica: la API de Jira cubre lectura y escritura de tickets, se entregó el token de integración ("PAF", vigente al 27-jul-2027) y se documentaron los límites de consumo de Atlassian. La estimación (~10 h) se comunicó a la PM el 21 de julio; esta sección la formaliza conforme al control de cambios (§10).

Entregables:

• Conexión con la API de Jira mediante el token PAF y lectura de los tickets de la bandeja Facturación (FAC-), con consumo autorregulado conforme a los límites de velocidad documentados por Atlassian.
• Generación automática de la cotización en BIND cuando un ticket alcanza el estatus disparador que Balam defina (candidato natural: la entrada del ticket al proceso de facturación, previo a "resuelto"), a través de la misma capa de escritura controlada del MVP.
• Trazabilidad ticket ↔ cotización ↔ prefactura/factura, visible en la plataforma y registrada en la bitácora de auditoría; los tickets leídos alimentan además la vista "qué necesita atención" del tablero.
• Pruebas controladas: scripts de consulta y de creación/edición sobre un registro de prueba, y una prueba observada con el equipo de Balam antes de habilitar la generación automática en operación.

No incluye: (a) el alta automática de clientes en BIND — si el cliente del ticket no existe, la plataforma lo detecta y lo notifica; darlo de alta automáticamente es una decisión de proceso abierta que, de aprobarse, se estima por separado; (b) tickets con múltiples facturas — el supuesto es un ticket → una cotización; el manejo del caso masivo se define junto con Balam y, si requiere desarrollo adicional, se estima por separado; (c) otros usos de Jira (reporteo de horas de consultores, tableros sobre otras bandejas, espacio comercial) y los módulos del Anexo B.

3.1Esquema: tiempo y materiales con tope por etapa

El proyecto se desarrolla bajo un esquema de horas reales con tarifa transparente, no de precio cerrado. El alcance preciso de la integración con BIND —campos exactos, comportamiento de Invoices y Payments, manejo de saldos— solo se conoce al inspeccionar la API en vivo con la cuenta de Balam. Un precio fijo obligaría a incorporar un margen de contingencia que encarecería el proyecto de forma innecesaria.

A cambio de esta flexibilidad, el esquema ofrece controles concretos:

• Rango estimado por etapa (mínimo–máximo de horas), acordado por escrito antes de iniciar cada una.
• Tope por etapa: de aproximarse al máximo del rango, el trabajo se detiene y se revisa el alcance con Balam antes de continuar. El rango opera como referencia de control, no como sugerencia.
• Reporte semanal de horas trabajadas con desglose por tarea.
• Demostración semanal del avance entregado.

3.2Dedicación y plazo

La dedicación es de media jornada (aproximadamente 20 h/semana, con flexibilidad hasta 25 h en semanas de mayor carga). Sobre esa base, la primera etapa requiere 121 a 148 horas (incluido el ajuste Jira → BIND), equivalentes a 6 – 8 semanas de calendario.

3.3Tarifa y facturación

• Tarifa: $600 MXN por hora trabajada + IVA, con comprobante fiscal CFDI 4.0. Aplica de igual forma a las fases posteriores (Anexo B) y al paquete de mantenimiento opcional (§5).
• Facturación: semanal, los viernes, por las horas de la semana previa. Cada factura incluye el anexo con el desglose de horas por tarea y etapa.
• Pago: a 30 días naturales posteriores a la factura, mediante transferencia. Aplica a todas las etapas.
• Sin anticipo (política Balam). Se emite factura por las primeras 30 horas de arranque al inicio; pago a 30 días. Arranque condicionado a contrato u orden de trabajo firmado.

3.4Comunicación

• Reportes asíncronos 2–3 veces por semana (avance, siguientes pasos y bloqueadores).
• Demostración semanal (30 min, viernes) con Pedro y la gerencia administrativa.
• Sesión técnica con Noe (1 h) para decisiones de arquitectura y validación de reglas de negocio, que podría realizarse al comenzar cada fase.
• Disponibilidad para reuniones urgentes con 24 h de anticipación, en horario laboral (9:00–18:00, CST).

3.5Metodología de desarrollo asistido por IA

El desarrollo se apoya en herramientas de asistencia por IA (Claude Code, de Anthropic) como acelerador de productividad. Por transparencia y cumplimiento, se hacen explícitos los siguientes compromisos:

• Responsabilidad humana. Todo el código entregado es revisado y validado por el proveedor. La IA es un asistente; la responsabilidad de cada línea integrada al repositorio es de Johann Velazquez.
• Protección de datos. Ningún dato real de Balam (clientes, montos, credenciales, XML reales) se comparte con modelos externos. El desarrollo se realiza con datos sintéticos derivados de la estructura, no del contenido. Las credenciales residen en gestores de secretos cifrados.
• Cumplimiento. La metodología se apega a la práctica habitual para el manejo de datos financieros: sin entrenamiento ni telemetría sobre datos del cliente, y con el código alojado en el repositorio de Balam desde el primer día.
• Auditabilidad. Las decisiones de arquitectura quedan registradas en ADRs versionados.

La inversión de la primera etapa se desglosa por entregable, conforme al esquema de tiempo y materiales:

5.1Garantía incluida

• Defectos en funcionalidad entregada: cobertura sin costo durante 45 días posteriores a la entrega de cada etapa.
• Soporte posterior al lanzamiento: 2 semanas tras el cierre del MVP, para corrección de defectos (no nuevo alcance).

5.2Bolsa de horas de soporte (opcional)

Concluida la garantía incluida, se ofrece una bolsa de horas a la misma tarifa de $600 MXN/h, con vigencia de 12 meses y sin caducidad mensual: las horas se consumen conforme se necesiten, sin obligación de uso mínimo por mes.

Incluye: corrección de defectos fuera de garantía; ajustes menores y requerimientos pequeños dentro de las horas de la bolsa; mantenimiento de dependencias y compatibilidad ante cambios de la API de BIND; monitoreo de la plataforma con atención a incidencias en 1 día hábil; y reporte de horas consumidas tras cada intervención.

No incluye: desarrollo de los módulos diferidos (Anexo B); migraciones o cambios mayores de arquitectura; ni incidentes atribuibles a terceros (Azure, BIND, SAT).

Términos: las horas tienen vigencia de 12 meses desde la compra de la bolsa, sin caducidad mensual ni compromiso mínimo; se consumen en incrementos de 15 minutos. Su activación es opcional y puede contratarse al cierre del MVP o más adelante.

Los siguientes son servicios de infraestructura externos, independientes de los honorarios del proveedor:

El cumplimiento de las estimaciones depende de las siguientes condiciones. De no satisfacerse alguna, la etapa correspondiente se replantea de común acuerdo:

1. Acceso productivo a la API de BIND, con los permisos definidos —lectura y escritura (creación de cotización y conversión a factura)— y documentación oficial disponible, al inicio de la Etapa 0.
2. Cuenta de Azure de Balam (o autorización para crearla a su nombre) disponible al inicio de la Etapa 0.
3. Manual de marca entregado al inicio de la Etapa 0.
4. Reglas de negocio finales validadas en Discovery: lista blanca de clientes (ACUNTIA + Top 3 confirmados), ciclos de cobranza, días de anticipación de alertas y frecuencia de sincronización.
5. Disponibilidad de dos interlocutores (Pedro y la gerencia administrativa) con capacidad de resolver bloqueadores en menos de 48 horas.
6. Producción como único ambiente disponible (sin sandbox de BIND). La plataforma opera en modo de simulación cuando exista riesgo de afectar BIND, requiriendo confirmación explícita antes de cualquier escritura.
7. Acuerdo de uso de la metodología asistida por IA, con el compromiso de no entrenamiento sobre datos del cliente.
8. El PAC integrado de BIND atiende los volúmenes actuales y futuros sin costo adicional; el timbrado CFDI permanece a cargo de BIND, no de la plataforma.
9. El comportamiento de escritura de la API de BIND (creación de cotización, conversión a factura y timbrado) se valida en Discovery; la emisión productiva se habilita únicamente tras esa validación. Balam designa al rol responsable de confirmar cada emisión.
10. Token de Jira ("PAF") vigente con visibilidad de la bandeja Facturación (FAC-), que opera como bandeja "padre" del proceso; si algún disparador nace en otra bandeja sin reflejarse en FAC, el ajuste se revisa en conjunto. Entregado el 27-jul-2026.
11. Definición del flujo de facturación cerrada por Balam (estatus disparador y reglas de prefactura) y diagrama del flujo Jira en tamaño legible entregado, antes de iniciar la implementación del ajuste Jira → BIND.

Más allá del código funcional, la entrega incluye:

• Código fuente en el repositorio de Balam (GitHub) desde el primer día; la propiedad intelectual es de Balam.
• Documentación técnica viva en el repositorio.
• Pruebas automatizadas para los flujos críticos (sincronización con BIND, lista blanca, multimoneda y control de acceso).
• Pipeline de CI/CD operativo, con despliegues controlados.
• Respaldos automatizados y plan de recuperación documentado.
• Sesión de transferencia de conocimiento grabada.
• Soporte posterior al lanzamiento de 2 semanas (corrección de defectos).

• Rediseño visual integral o sistema de diseño propio (se emplea la identidad del manual de marca de Balam; un diseño a la medida requeriría sumar un diseñador).
• Adquisición de licencias de terceros (PAC, agregadores, hosting Azure).
• Gestión del cambio organizacional más allá de la sesión de capacitación.
• Módulos diferidos: pagos en línea, recordatorios automáticos a clientes, conciliación bancaria, asientos contables, BUK e IA — cotizados de forma indicativa en el Anexo B.
• Integraciones no listadas (Book, CRM, etc.), cotizables por separado.
• Adaptaciones derivadas de cambios fiscales del SAT o modificaciones disruptivas en la API de BIND que impliquen retrabajo mayor (atendibles mediante el paquete de mantenimiento, §5.2).

• Garantía de defectos: cobertura sin costo durante 45 días posteriores a la entrega de cada etapa.
• Control de cambios: toda funcionalidad fuera del alcance acordado se documenta como solicitud de cambio (Change Request), se estima y se aprueba por escrito antes de ejecutarse.
• Propiedad intelectual: el código es propiedad de Balam desde el primer commit. El proveedor conserva el derecho de referir el proyecto en su portafolio sin divulgar información confidencial.
• Responsabilidad del código asistido por IA: todo defecto queda cubierto por la misma garantía. La responsabilidad final del código corresponde al proveedor, con independencia de las herramientas utilizadas.

1. Firma del contrato u orden de trabajo (prestación de servicios y confidencialidad).
2. Emisión de la primera factura por 30 horas de arranque ($18,000 MXN + IVA) e inicio del Discovery; pago a 30 días naturales.
3. Arranque del proyecto, con entrega del MVP en 6 – 8 semanas.
4. Aprobación por escrito de la versión 1.3 (basta la confirmación por correo electrónico) para ejecutar el ajuste Jira → BIND de 9 – 12 h una vez definido el flujo de facturación.

Este anexo relaciona cada funcionalidad y requerimiento del PRD de Balam con el alcance comprometido en la primera etapa, como referencia para alinear expectativas sobre lo incluido, lo parcial y lo diferido.

A.1Funcionalidades (PRD §3.1)

Facturación

Cobranza

Conciliación bancaria

Contabilidad

Reportes y alertas

A.2Requerimientos funcionales (PRD §6)

A.3Requerimientos no funcionales (PRD §7)

A.4Diferidos — resumen

Diferido por decisión de alcance

Pagos en línea; recordatorios automáticos a clientes; conciliación bancaria; asientos contables automáticos; EUR; flujo de efectivo proyectado; detección avanzada de anomalías; portal de cliente; multi-tenant comercial; cumplimiento avanzado Texas.

Los siguientes son rangos indicativos, no compromisos contractuales. Se reconfirman mediante su propio Discovery al activar cada módulo, con datos reales de uso del MVP. La tarifa de $600 MXN/h y el esquema de tiempo y materiales con tope por etapa se mantienen.

B.1Módulos cotizados

B.2Roadmap posterior (sin cotización)

Se cotiza al cierre de la fase anterior, priorizando con datos reales de uso: integración bancaria en vivo (Belvo, Plaid); conector con BIND para asientos contables automáticos; ampliaciones de la integración con Jira (otras bandejas, reporteo de horas, espacio comercial); flujo de efectivo proyectado (30/60/90 días); gestión cambiaria automática; pagos recurrentes; detección avanzada de anomalías; soporte EUR; clasificación asistida por IA; portal de cliente; multi-tenant comercial; aplicación móvil para tickets; y cumplimiento avanzado para Texas.

B.3Activación

Al cierre del MVP se realiza una sesión de priorización (1 h) y se formaliza una orden de trabajo por módulo seleccionado. La tarifa, el esquema, la comunicación y la garantía aplican en los mismos términos que en la primera etapa (sin anticipo; facturación al inicio de cada módulo, pago a 30 días).