JohannVelazquez
650 lines
58 KiB
Markdown
650 lines
58 KiB
Markdown
# REGISTRO · Bitácora de comunicaciones — Proyecto Balam
|
||
|
||
> Log cronológico de **toda** comunicación del proyecto (correos, llamadas, mensajes). Es la fuente de la verdad del "qué se dijo y cuándo". Convención y plantillas para registrar en [README.md](README.md). Material crudo (transcripciones, .eml, PRD) en [`../fuentes/`](../fuentes/).
|
||
|
||
**Hilo de correo principal:** "Re: Solicitud de cotización – PRD"
|
||
**Participantes:**
|
||
- **Johann** (proveedor) — `johann_antonio85@hotmail.com`
|
||
- **Noe Rocha** — CTO, Balam — `noe.rocha@balamtalentoestrategico.com`
|
||
- **Araceli Sanchez Jimenez** ("Ara") — Balam — `araceli.sanchez@balamtalentoestrategico.com`
|
||
- **Erika Chavez** — Project Manager, Balam — `erika.chavez@balamtalentoestrategico.com` · WhatsApp +52 1 81 2353 5803
|
||
- **Pedro Alberto Ayala Elizondo** — Desarrollador / contacto técnico, Balam — `pedro.ayala@balamtalentoestrategico.com`
|
||
- **Paola** — Recursos Humanos, Balam — coordinó la firma del contrato (WhatsApp)
|
||
|
||
**Periodo:** 30 abr 2026 → 6 jul 2026 (última actualización: sesión de Discovery del proceso de facturación, 6-jul)
|
||
**Orden:** cronológico (más antiguo arriba)
|
||
|
||
---
|
||
|
||
## 1 · Apr 30, 2026 — 4:38 PM · Erika Chavez → Johann
|
||
|
||
> **Asunto:** Solicitud de cotización – PRD
|
||
> **CC:** Noe Rocha, Araceli Sanchez
|
||
|
||
Buenas tardes,
|
||
|
||
Espero que se encuentren muy bien. Mi nombre es Erika Chávez, Project Manager en Balam. Es un gusto saludarte, Johann.
|
||
|
||
Por medio de este medio, te comparto el PRD con la finalidad de solicitar tu apoyo en la elaboración de la cotización correspondiente.
|
||
|
||
Quedo atenta a cualquier duda o comentario.
|
||
|
||
Saludos.
|
||
|
||
---
|
||
|
||
## 2 · May 4, 2026 — 3:30 PM · Johann → Erika (CC Noe, Ara)
|
||
|
||
Buenos días Araceli,
|
||
|
||
Gracias por compartir el PRD, ya lo revisé a detalle durante el fin de semana. El alcance está muy claro y bien estructurado.
|
||
|
||
Para preparar la propuesta técnica con una estimación precisa por fase, me surgen las siguientes preguntas:
|
||
|
||
### Integraciones
|
||
- ¿BIND ERP tiene API habilitada o se trabaja con exportación de archivos?
|
||
- ¿BUK expone API para consultar nómina procesada?
|
||
- ¿Los 3 bancos entregan estados de cuenta por API, archivos (CSV/OFX) o PDFs?
|
||
- ¿Cuál es el banco americano que manejan?
|
||
- ¿Pueden dar acceso a ambientes sandbox de BIND y BUK para desarrollo, o solo cuentan con producción?
|
||
|
||
### Facturación
|
||
- ¿Ya cuentan con un PAC contratado para timbrado CFDI? ¿Cuál?
|
||
- La facturación a clientes en Texas, ¿es invoice estándar o requiere tax compliance específico?
|
||
- El PRD menciona soporte para EUR en RF-02, pero la regla de facturación internacional refiere solo a USD. ¿Confirman que el MVP debe incluir EUR, o lo dejamos preparado para una fase posterior?
|
||
|
||
### Cobranza
|
||
- El PRD indica que ACUNTIA y los "top 3 clientes" no deben recibir recordatorios automáticos. ¿Quiénes son esos top 3? ¿Es una lista fija o configurable?
|
||
- Se menciona el uso de tickets físicos en pagos con tarjeta como problema actual. ¿Esto se refiere a pagos con terminal donde el registro es manual?
|
||
|
||
### Datos y sistemas
|
||
- ¿"Book" es un sistema interno? ¿Cuenta con API o base de datos accesible?
|
||
- ¿Jira se usa únicamente para gestión de proyectos o también como fuente de datos de clientes/colaboradores?
|
||
|
||
### Operación
|
||
- ¿Aproximadamente cuántos colaboradores tienen en nómina y cuántas facturas emiten al mes?
|
||
- ¿Quién sería el contacto operativo para validar reglas de negocio durante el desarrollo?
|
||
|
||
### Infraestructura y diseño
|
||
- ¿Tienen servidor o nube preferida para hospedar la plataforma, o propongo opciones?
|
||
- ¿Cuentan con guía de marca / assets (logo, colores, tipografía) para la plataforma, o se diseña desde cero?
|
||
|
||
Con estas respuestas puedo tener la propuesta lista en 24–48 horas. Si prefieren, podemos agendar una sesión corta de 20–30 minutos para revisarlas en conjunto.
|
||
|
||
---
|
||
|
||
## 3 · May 4, 2026 — 7:59 PM · Noe Rocha → Johann (respuestas inline)
|
||
|
||
> Hola Johan, te paso los comentarios más abajo de lo que sé; algunos los tengo que investigar y otros los puede responder o aclarar Ara (TBD Ara).
|
||
|
||
| Pregunta | Respuesta de Noe |
|
||
|---|---|
|
||
| ¿BIND ERP tiene API habilitada? | **Exportación de archivos** |
|
||
| ¿BUK expone API? | **No hasta donde sabemos** |
|
||
| ¿Estados de cuenta de los 3 bancos? | **PDFs** |
|
||
| ¿Cuál es el banco americano? | TBD Ara |
|
||
| ¿Sandbox de BIND y BUK? | **Solo producción** |
|
||
| ¿PAC contratado para CFDI? | **Integrado en el mismo sistema de BIND** (hasta donde sabe) |
|
||
| ¿Facturación a Texas, tax compliance? | TBD Ara |
|
||
| ¿EUR en MVP? | **Dejarlo preparado para fase posterior. Por el momento solo USD** con empresas europeas |
|
||
| ¿Quiénes son ACUNTIA + top 3, lista fija o configurable? | **Lista configurable de acuerdo al objetivo de negocio** |
|
||
| ¿Tickets físicos en pagos con tarjeta? | TBD Ara |
|
||
| ¿"Book" es interno?, ¿API? | **Es un SaaS** |
|
||
| ¿Jira para qué se usa? | **Gestión de proyectos y servicios solamente con clientes** |
|
||
| ¿Cuántos colaboradores y facturas/mes? | **45 colaboradores + 5 proveedores tipo freelancer** |
|
||
| ¿Contacto operativo durante desarrollo? | **Un servidor (Noe) y el gerente administrativo** |
|
||
| ¿Nube preferida? | **Preferentemente Azure**; si hay mejor costo-beneficio, abiertos a evaluar |
|
||
| ¿Guía de marca / assets? | TBD Ara |
|
||
|
||
---
|
||
|
||
## 3a · May 6, 2026 — Araceli Sánchez → Johann · respuestas "en verde"
|
||
|
||
> **Asunto:** Re: Solicitud de cotización – PRD
|
||
> *(Fuente: lista del hilo de Outlook. Su contenido íntegro no consta en el `.eml` disponible — ver aviso.)*
|
||
|
||
*"Te respondo en verde. Gracias, Saludos."* Araceli responde los puntos que Noe dejó marcados **TBD Ara** el 4-may: **(1)** banco americano, **(2)** tax compliance para clientes en Texas, **(3)** tickets físicos en pagos con tarjeta, **(4)** guía de marca / assets.
|
||
|
||
> ⚠️ **Evidencia pendiente:** el texto exacto de las respuestas "en verde" **no está en el `.eml` disponible** (capturado el 3-jun, donde esos 4 puntos aún figuran resaltados en amarillo como "TBD Ara", sin responder). **Acción:** recuperar el correo verde original para transcribir las respuestas aquí. El Resumen ejecutivo infiere banco = **IBC Bank Texas** y tax = **estándar** a partir de la llamada del 19-may; falta confirmar la atribución a este correo.
|
||
|
||
---
|
||
|
||
## 3b · May 6, 2026 — Johann → Balam · acuse
|
||
|
||
> **Asunto:** Re: Solicitud de cotización – PRD
|
||
> *(Fuente: lista del hilo de Outlook.)*
|
||
|
||
*"Muchas gracias por sus comentarios. Los incorporo a la propuesta y se las comparto a la brevedad."* Johann acusa recibo de las respuestas (Noe inline + Araceli en verde) y anuncia que las incorpora a la propuesta.
|
||
|
||
---
|
||
|
||
## 4 · May 8, 2026 — 5:06 PM · Johann → Noe
|
||
|
||
Hola Noe,
|
||
|
||
Antes de compartirles la propuesta técnica final, me gustaría agendar una sesión contigo para revisar algunos puntos que impactan directamente el alcance:
|
||
|
||
1. **Dashboards:** ¿Qué campos e indicadores necesitan visualizar por módulo (facturación, cobranza, conciliación)? Quiero asegurarme de que el diseño refleje exactamente lo que el equipo de finanzas y dirección necesita ver.
|
||
2. **Mapa técnico de datos:** Sería muy útil que en la llamada me pudieras mostrar los sistemas desde donde sacaremos la información — qué sale de BUK, qué está en BIND, qué está en Book y cómo interactúan hoy. Esto me ayudará a dimensionar mejor la parte de integración y asegurar que no haya sorpresas durante el desarrollo.
|
||
3. **Acceso a bancos:** Si en algún punto se busca integración vía API bancaria, conviene definirlo desde ahora para contemplarlo en el alcance desde el inicio.
|
||
|
||
¿Tienes disponibilidad para una sesión de 30–45 minutos?
|
||
|
||
---
|
||
|
||
## 5 · May 11, 2026 — 5:47 PM · Noe → Johann
|
||
|
||
Hola Johan,
|
||
|
||
Te paso opciones para una reunión:
|
||
|
||
- Miércoles de 7am a 8am, 6pm a 7pm
|
||
- Jueves de 7am a 8am
|
||
|
||
Te doy opciones muy temprano o muy tarde para que se te acomode en tu horario. Si hay tiempo para ti de verlo en horarios intermedios nos podemos adecuar.
|
||
|
||
---
|
||
|
||
## 6 · May 12, 2026 — 10:27 PM · Johann → Noe
|
||
|
||
Hola Noe,
|
||
|
||
Jueves de 7-8am me parece bien.
|
||
|
||
Saludos.
|
||
|
||
---
|
||
|
||
## 7 · May 16, 2026 — 10:32 AM · Noe → Johann
|
||
|
||
Buenos días Johan,
|
||
|
||
¿Podemos tener la sesión este martes? O bien, si es algo de una llamada, ¿a qué número te podría marcar?
|
||
|
||
> *(Implícita: la llamada se sostuvo el martes 19 de mayo de 2026 — transcripción en `../fuentes/2026-05-19 - Transcript - Solicitud de cotizacion.txt`.)*
|
||
|
||
---
|
||
|
||
## 7a · May 16, 2026 — Johann → Noe · confirma sesión + comparte teléfono
|
||
|
||
> **Asunto:** Re: Solicitud de cotización – PRD
|
||
> *(Fuente: lista del hilo de Outlook.)*
|
||
|
||
*"Buen día Noe, claro, este martes podemos tener sesión. Cualquier cosa te comparto mi número: 8131610998. Saludos."* (La sesión se sostuvo el martes 19-may; ver #7.)
|
||
|
||
---
|
||
|
||
## 8 · May 25, 2026 — 10:41 PM · Noe → Johann
|
||
|
||
Hola Johann,
|
||
|
||
En el caso de **Bind tiene una API** que veo factible que podamos usar para nuestra necesidad:
|
||
|
||
- [Referencia API · Portal de desarrolladores · Bind ERP](https://developers.bind.com.mx/api-details#api=bind-erp-api&operation=Activities_AddActivity)
|
||
- [API de Bind ERP — sitio de ayuda](https://ayuda.bind.com.mx/hc/es/articles/360007437754-api-de-bind-erp)
|
||
|
||
Como dato tiene un **límite de 20 mil solicitudes diarias**, no sé si es poco o mucho para nuestra necesidad, pero hay que tomarlo en cuenta.
|
||
|
||
Como nuestro **primer interés es el tema de facturación**, considero que la propuesta sería **primero solo considerando el sistema ERP Bind**.
|
||
|
||
Saludos.
|
||
|
||
---
|
||
|
||
## 9 · May 27, 2026 — AM · Pedro (desarrollador, Balam) → Johann ⭐ (último mensaje)
|
||
|
||
Buenos días Johan,
|
||
|
||
Espero te encuentres bien. Quiero compartirte una **actualización respecto a nuestra plataforma BUK**: confirmamos que sí cuenta con **soporte API para integraciones con herramientas externas**. Puedes consultar la documentación disponible en el siguiente enlace.
|
||
|
||
> *(Nota: el link al API no se incluyó en el mensaje recibido; pendiente solicitarlo en la respuesta.)*
|
||
|
||
Aunque **esta integración no es prioridad en este momento**, queremos que cuentes con esta información para que puedas preparar una propuesta cuando sea oportuno avanzar con el tema.
|
||
|
||
En cuanto tengamos mayor claridad sobre los tiempos, te los haremos saber.
|
||
|
||
¡Saludos!
|
||
|
||
> **Lectura estratégica:**
|
||
> - Pedro está ejecutando lo que Noe le pidió en la llamada del 19-may (acelerar con BUK / Book / proveedores).
|
||
> - **No cambia el alcance del MVP** — BUK sigue siendo Fase 2 post-MVP.
|
||
> - **Sí confirma viabilidad técnica** del ciclo end-to-end Jira → BUK → Plataforma → BIND para Fase 2.
|
||
> - Pedro perfila como **contacto técnico día a día** durante el proyecto (responde la pregunta abierta del checklist).
|
||
|
||
---
|
||
|
||
## 10 · May 29, 2026 — 2:44 PM · Johann → Noe (CC Ara, Erika, Pedro) · envío de la propuesta
|
||
|
||
> **Asunto:** Re: Solicitud de cotización – PRD
|
||
> Evidencia: hilo `../fuentes/RE_ Solicitud de cotización – PRD (1).eml` (en este punto Pedro ya aparece en CC). Adjunta la **propuesta v1.0** en PDF. El cuerpo del correo ("Adjunto la propuesta para la plataforma de automatización financiera que conversamos…") consta dentro del `.eml`.
|
||
|
||
Envío de la **propuesta v1.0 en PDF** (`Propuesta-Balam.pdf`). MVP BIND-first enfocado en facturación: consulta + **emisión asistida** de facturas MXN/USD vía API de BIND (con dry-run + confirmación humana; timbra el PAC de BIND), cobranza operativa (aging, alertas internas, lista blanca ACUNTIA + Top 3), dashboard, reportes y bitácora. Inversión **$67,200 – $81,600 MXN + IVA**, **6–7 semanas**, anticipo de 30 h (**$18,000 + IVA**) para Discovery. Módulos diferidos (conciliación, Stripe, recordatorios a clientes, asientos, BUK) cotizados de forma indicativa en el **Anexo B**.
|
||
|
||
---
|
||
|
||
## 11 · Jun 2, 2026 — 5:33 PM · Pedro → Johann, Noe (CC Ara, Erika)
|
||
|
||
> **Asunto:** RE: Solicitud de cotización – PRD
|
||
|
||
"Buenas tardes, Johan. Gracias por compartir la propuesta. @Noe Rocha y yo la hemos revisado y tenemos **varios comentarios** que nos gustaría compartir contigo directamente en una **sesión conjunta**. ¿Nos podrías compartir tu disponibilidad para mañana por la tarde, o tu horario de preferencia para el jueves 4 de junio?"
|
||
|
||
---
|
||
|
||
## 12 · Jun 2, 2026 — 9:39 PM · Johann → Pedro, Noe (CC Ara, Erika)
|
||
|
||
> *"Buen día, Pedro: Claro que sí, con gusto. Me funcionaría mejor el jueves 4 de junio a las 7:00 am para revisar los comentarios juntos. Si a esa hora no l[es funciona]…"* (vista previa)
|
||
|
||
---
|
||
|
||
## 13 · Jun 3, 2026 · Pedro → Johann, Noe (confirmación + liga Teams)
|
||
|
||
> *"Buenos días, Johan. Te agendo para el día de mañana a las 7 am. Te comparto el link de la sesión. Reunión de Microsoft Teams — Unirse: https://teams.microsoft.com/meet/22…"* (vista previa)
|
||
|
||
Queda confirmada la sesión: **jueves 4-jun, 7:00 am, por Microsoft Teams**.
|
||
|
||
---
|
||
|
||
## 14 · Jun 4, 2026 — 7:00 AM · Llamada de revisión de propuesta ⭐
|
||
|
||
> Participan: Noe, Pedro, Erika y Johann. Transcripción completa en `../fuentes/2026-06-04 - Transcript - Revision de propuesta.txt`.
|
||
|
||
**Veredicto general:** *"En términos generales, la propuesta está bien."* El proyecto **avanza**; hay puntos a negociar/ajustar antes de formalizar.
|
||
|
||
**Acuerdos y decisiones:**
|
||
1. **Anticipo $18,000 (Discovery): APROBADO.** Arrancan con eso; el monto final del MVP se aclara tras Discovery (Noe entiende que el rango $67.2K–$81.6K depende de lo que se encuentre).
|
||
2. **Conciliación: Noe la quiere incluir** (hoy es 100% manual y ya es un problema real). Vio que está cotizada en el Anexo B (~$48–63K). Condicional al flujo: si facturación queda en ~$67K pediría conciliación **de inmediato**; si sube a $81.6K, evaluará tiempos/flujo en las próximas semanas. Enfoque platicado: estados de cuenta PDF → extracción (librerías/OCR/IA) → **matching por algoritmo (~98%)** usando la API de BIND para las facturas. Involucrar a **Arturo** (bancos).
|
||
3. **Dashboard/reporteo: posible recorte.** Balam **ya tiene un tablero Power BI** (hecho por Pedro) que resuelve antigüedad de cartera; Noe no quiere pagar por lo que ya tienen. **Sí quiere el módulo de cobranza + alertas internas** (que el tablero no ejecuta). Validar con Pedro qué del dashboard es redundante.
|
||
4. **Lista blanca:** confirmado que es **configurable**, no limitada a 3.
|
||
5. **Soporte/mantenimiento:** a Noe no le gusta la caducidad de horas a 30 días ("úsalo o lo pierdes"); pide **negociar mayor vigencia**. Johann: negociable.
|
||
6. **API BIND:** Pedro hoy usa la llave de **Araceli** para el Power BI; para desarrollo se usará otra (de **Arturo**, mismos permisos). BIND parece permitir **1 API key por usuario** (Pedro confirmará); generarlas desde la **cuenta maestra (ARA)** y **documentar cuál es para qué**.
|
||
7. **Azure:** se gestiona con **Guajardo / Erika**. Johann requiere permisos para crear App Service + PostgreSQL (no Global Admin).
|
||
8. **Manual de marca:** existe (paleta, tipografía, logos); **Pedro lo envía**.
|
||
9. **Reglas de negocio:** se definen con **Arturo + Pedro**.
|
||
10. **Metodología IA:** aclarado = no se entrenan modelos con datos de Balam. Noe OK.
|
||
11. **Pagos:** anticipo a **7 días** OK; **avances a 30 días** (Balam cobra a sus clientes a 60–120 días; 30 es el mínimo negociado). Johann aceptó.
|
||
12. **Gestión del proyecto:** en **Jira** (estilo ágil/Yael, no Gantt). Pedro crea el espacio (plan free); **Erika valida entregables** para el pago.
|
||
13. **Comunicación:** canal de **WhatsApp** + correo para evidencia formal. **Erika = contacto principal · Pedro = técnico · Arturo = negocio.**
|
||
14. **Fiscal (Johann):** en proceso de cambiar régimen (24 h); confirma que **sí puede facturar**.
|
||
15. **Inicio:** Johann puede empezar **cuanto antes**, de preferencia inicio de semana para coordinar con Arturo.
|
||
|
||
**Próximos pasos definidos en la llamada:**
|
||
- **Noe formaliza por correo a partir del 5-jun:** solicita **factura de anticipo**, envía info/accesos y los **ajustes a la propuesta** para arrancar.
|
||
- **Johann:** cambiar régimen fiscal (24 h), emitir factura de anticipo, preparar Discovery.
|
||
- **Pedro:** enviar manual de marca; revisar llaves API (cuántas por usuario, generar desde ARA); crear proyecto en Jira.
|
||
- **Pendiente con Arturo:** reglas de negocio + acceso a bancos (conciliación).
|
||
- **Azure:** gestionar con Guajardo/Erika.
|
||
|
||
---
|
||
|
||
## 15 · Jun 8, 2026 — 6:15 PM · Correo · Noe → Johann (CC Ara, Erika, Pedro) · aclaraciones y preguntas
|
||
|
||
> Evidencia: `../fuentes/2026-06-08 - Correo - Noe aclaraciones y preguntas.md`. Re-adjunta `Propuesta-Balam.pdf`.
|
||
|
||
Noe formaliza por escrito 4 aclaraciones/ajustes y 3 preguntas, antes de avanzar:
|
||
|
||
**Ajustes solicitados:**
|
||
1. La inversión final del módulo de facturación queda **supeditada al Discovery** (112 vs 136 h, 6–7 sem). — *De acuerdo, así estaba planteado.*
|
||
2. **Soporte:** el límite de consumo **mensual** es limitante; piden **bolsa de horas vigente 12 meses** (paquetes por hora, no mensualidad con caducidad).
|
||
3. **Garantía:** piden **45 días** (no 30) — el ciclo financiero es mensual y los defectos no se ven hasta pasado el cierre.
|
||
4. **Sin anticipos** (política Balam) y **pago estricto a 30 días** post-factura. Proponen: Johann **factura las 30 h de la Etapa 0** y se programa el pago a 30 días.
|
||
|
||
**Preguntas:**
|
||
- ¿Qué pasa si el Discovery revela que la **API de BIND no soporta la escritura/emisión** esperada?
|
||
- Si el Discovery **reduce horas**, ¿se puede **adelantar algo de conciliación**?
|
||
- Sin sandbox, ¿qué **garantías concretas** contra una **emisión errónea con efecto fiscal**? ¿Hay **reversa/cancelación** contemplada?
|
||
|
||
**Acción Johann:** responder el correo (respuestas + postura comercial) y reflejar los cambios en la **propuesta v1.1**. Decisión clave: aceptar el esquema **sin anticipo / pago a 30 días** (impacto en flujo). Ver [PENDIENTES.md](PENDIENTES.md).
|
||
|
||
---
|
||
|
||
## 16 · Jun 10, 2026 — 6:11 PM · Johann → Noe (CC Ara, Erika, Pedro) · respuesta + propuesta v1.1
|
||
|
||
> **Asunto:** RE: Solicitud de cotización – PRD
|
||
> **CC:** Araceli Sánchez, Erika Chávez, Pedro Ayala
|
||
> Evidencia: `../fuentes/2026-06-10 - Correo - Johann respuesta v1.1.md`. Adjunta `Propuesta-Balam.pdf` (v1.1).
|
||
|
||
Johann responde el correo del 8-jun, **acepta los 4 ajustes** y contesta las 3 preguntas técnicas; reenvía la **propuesta v1.1**.
|
||
|
||
**Respuesta a los ajustes:**
|
||
1. **Inversión** del módulo de facturación: de acuerdo, se confirma con el Discovery (112–136 h, 6–7 semanas).
|
||
2. **Soporte:** de acuerdo. Replanteado como **bolsa de horas a $600/h + IVA, vigencia 12 meses** desde su contratación, sin caducidad mensual.
|
||
3. **Garantía:** de acuerdo, **45 días** (cubre el primer cierre mensual).
|
||
4. **Sin anticipo / pago a 30 días:** de acuerdo. Factura las **30 h de la Etapa 0** al inicio y el pago corre a 30 días, igual que los avances. **Única condición:** dejar **firmado el contrato/orden de trabajo antes de iniciar** (la firma formaliza el compromiso y le permite arrancar de inmediato).
|
||
|
||
**Respuesta a las preguntas:**
|
||
- **Si BIND no soporta escritura/emisión:** es lo que el Discovery valida antes de construir. Si no es viable o implica riesgo, la facturación se entrega en **modo asistido** (la plataforma prepara y valida; la emisión final se confirma en BIND) y se reajusta el alcance del módulo. No se invierte en construir algo que no funcione.
|
||
- **Si el Discovery reduce horas:** sí, la capacidad liberada puede arrancar un **primer alcance de conciliación**, con mini-scope y estimación al cierre del Discovery.
|
||
- **Garantías sin sandbox / reversa:** la emisión tiene **cinco candados** — lectura primero, validación en Discovery, dry-run antes de cada emisión, confirmación humana obligatoria por factura y feature flag apagado por defecto. La plataforma no auto-emite; el timbrado lo hace el PAC de BIND. La cancelación de un CFDI corre por el proceso fiscal BIND/SAT (con su ventana de aceptación); la plataforma puede disparar/registrar esa solicitud vía API de BIND si la soporta — a confirmar en Discovery.
|
||
|
||
> **Lectura estratégica:**
|
||
> - Johann **cede en lo comercial** (sin anticipo, 30 días, 45 días garantía, soporte 12 meses) pero **fija un candado propio: firma del contrato antes de arrancar**, que sustituye al anticipo como mecanismo de compromiso. Es el punto a vigilar.
|
||
> - Las 3 respuestas técnicas **desactivan los riesgos** que Noe planteó sin ampliar alcance: el Discovery sigue siendo la red de seguridad.
|
||
> - La conciliación queda **explícitamente condicionada** a horas liberadas por el Discovery — coherente con lo que Noe pidió el 4-jun.
|
||
|
||
---
|
||
|
||
## 17 · Jun 16, 2026 — 3:35 PM · Noe → Johann, Pedro (CC Ara, Erika) · luz verde ⭐
|
||
|
||
> **Asunto:** Solicitud de cotización – PRD
|
||
> **CC:** Araceli Sánchez, Erika Chávez
|
||
> Evidencia: `../fuentes/2026-06-16 - Correo - Noe luz verde y documento de firma.md`. Adjunto: Outlook-p2vlyjhm (50 KB). _(Hora 3:35 PM tomada de la captura del correo.)_
|
||
|
||
Balam da **luz verde** a los términos de la v1.1. Noe confirma:
|
||
|
||
- *"Estamos de acuerdo con lo que se definió."* Balam **ya está redactando el documento para firmar** estos acuerdos.
|
||
- Pide a Johann **esperar** a que le envíen todo para los siguientes pasos (queda en hold del lado del proveedor).
|
||
- Instruye a **Pedro** a **armar el tablero de seguimiento en JIRA** y **revisarlo con Erika** para el seguimiento del proyecto de desarrollo, "para ir preparando el camino".
|
||
|
||
> **Lectura estratégica:**
|
||
> - **Hito comercial:** el cliente acepta formalmente la propuesta v1.1. El proyecto pasa de "negociación" a "preparación de firma".
|
||
> - La pelota está **del lado de Balam**: redactar el documento de firma. Johann debe **revisarlo cuando llegue** (verificar que recoja: sin anticipo + firma previa, 30 días de pago, 45 días de garantía, soporte bolsa 12 meses, alcance MVP BIND-first y el condicionante de Discovery) antes de firmar.
|
||
> - Se **activa el tablero Jira** (Pedro + Erika), tal como se acordó el 4-jun — primer paso operativo real.
|
||
> - No hay accesos ni fecha de arranque todavía: el Discovery no inicia hasta que llegue el documento firmado + los accesos.
|
||
|
||
---
|
||
|
||
## 18 · Jun 25, 2026 — Balam (vía Paola, RH) → Johann · contrato de servicios para firma
|
||
|
||
> Evidencia: `../fuentes/2026-06-26 - WhatsApp - Paola (RH) ajustes y firma de contrato.md`. Contrato: `../propuesta/2026_06-25_12-13__Contrato_de_servicios_profesionales__Johann_Joseph_Velazquez_Antonio.pdf`.
|
||
|
||
Balam envía el **Contrato de Prestación de Servicios Profesionales** (PDF) para firma, coordinado por **Paola (Recursos Humanos)** vía WhatsApp. Es el "documento de firma" que Noe anunció el 16-jun (#17). Recoge los términos v1.1: sin anticipo, pago a 30 días, garantía 45 días, alcance MVP BIND-first, firma como condición de arranque, propiedad intelectual de Balam, y **facturación semanal (viernes)** por horas trabajadas. Johann pide corregir su segundo nombre ("Josep" → "Joseph"); Paola corrige.
|
||
|
||
---
|
||
|
||
## 19 · Jun 26, 2026 — WhatsApp Johann ↔ Paola (RH) · ajustes finales y FIRMA del contrato ⭐
|
||
|
||
> Evidencia: `../fuentes/2026-06-26 - WhatsApp - Paola (RH) ajustes y firma de contrato.md`. Contrato firmado: `../propuesta/2026_06-26_14-19__Contrato_de_servicios_profesionales__Johann_Joseph_Velazquez_Antonio.pdf`.
|
||
|
||
Johann revisa el contrato a detalle y plantea observaciones por WhatsApp. **Balam acepta 2 ajustes** y los agrega (nueva cláusula "Terminación anticipada, pago de servicios y aceptación de entregables"):
|
||
1. **Pago al terminar:** en terminación anticipada se pagan las **horas efectivamente trabajadas** hasta la fecha.
|
||
2. **Aceptación de entregables:** se dan por aceptados si no hay comentarios por escrito en **10 días naturales**; correcciones limitadas al alcance pactado.
|
||
|
||
**Correcciones aplicadas:** firmas → "EL CLIENTE / EL PRESTADOR DE SERVICIOS" (se quitó "TRABAJADOR"); se eliminó el párrafo "Para constancia" duplicado.
|
||
|
||
**Johann FIRMA el contrato** (firma electrónica, 26-jun 14:48, RFC VEAJ031228MD6).
|
||
|
||
> **Lectura estratégica:**
|
||
> - **Cierre formal del cierre comercial.** El proyecto queda contratado; falta que Balam entregue los **accesos** para arrancar.
|
||
> - **Residuo (bajo riesgo):** la cláusula "Firma Electrónica" de la última página quedó **duplicada** y aún dice **"EL PATRÓN"** (residuo de plantilla). Opcional pedir copia limpia; el resto del contrato define bien a las partes y declara que no hay relación laboral.
|
||
> - **Términos NO incluidos** (Johann decidió no insistir): tope/límite de responsabilidad, rescisión recíproca, metodología IA, "lugar de servicios", bolsa de horas 12 meses.
|
||
> - **Facturación semanal (viernes)** por horas + 30 días — distinto del "por etapa" de la propuesta; es lo vinculante.
|
||
|
||
---
|
||
|
||
## 20 · Jun 29, 2026 — WhatsApp Erika → Johann · arranque del plan de actividades ⭐
|
||
|
||
> Evidencia: `../fuentes/2026-06-29 - WhatsApp - Erika arranque del plan de actividades.md`.
|
||
|
||
Erika (PM, contacto principal) confirma que **ya pasaron los temas administrativos internos de Balam** y arranca la coordinación de ejecución. Pide a Johann un **listado de actividades con fechas (Excel)** por **etapas** (como en la propuesta), empezando por **Etapa 0 y 1**: actividad · fecha inicio–fin · responsable, **alineado a los entregables**, indicando dónde requiere apoyo de Balam. Ofrece llamada de 5 min.
|
||
|
||
> **Lectura estratégica:**
|
||
> - El proyecto entra en **fase de ejecución / kickoff**.
|
||
> - Acción de Johann: preparar el **Excel de actividades (Etapa 0 y 1)** y proponer **sesiones de Discovery** (conocer el proceso actual + encaminar el prototipo) — parte de la Etapa 0; el contrato ya obliga a Balam a dar disponibilidad de interlocutores.
|
||
> - Sigue pendiente que Balam entregue los **accesos** (API BIND, Azure, manual de marca, reglas con Arturo).
|
||
|
||
---
|
||
|
||
## 21 · Jun 29–30, 2026 — WhatsApp Johann ↔ Erika · plan de actividades entregado + kickoff agendado ⭐
|
||
|
||
> Evidencia: `../fuentes/2026-06-29 - WhatsApp - Erika arranque del plan de actividades.md`. Plan: `../planeacion/Plan-actividades.xlsx` (+ `.md`).
|
||
|
||
- Johann entrega el **plan de actividades** (Excel sencillo: actividad · fecha inicio–fin · responsable · apoyo de Balam): primero Etapa 0 y 1 (29-jun) y luego **enviado completo, las 4 etapas (0–3)** con fechas tentativas (**30-jun, 12:34**). Las sesiones quedan ubicadas por etapa; la Etapa 0–1 se mantiene idéntica a lo enviado el 29-jun.
|
||
- **Erika confirma que será la intermediaria** de todas las sesiones ("lo que necesites me lo pides y yo coordino agendas").
|
||
- **Kickoff con el Ing. Noé CONFIRMADO: miércoles 1-jul, 7:00 am.**
|
||
- Erika está montando el **tablero Kanban en Jira** para el seguimiento (mide avance por %).
|
||
|
||
> **Lectura estratégica:**
|
||
> - Arranca la operación: el 1-jul es el kickoff. Etapa 0 (ejecución) planeada para la **semana del 6-jul**, condicionada a accesos.
|
||
> - Erika como **punto único de coordinación de sesiones** simplifica la logística (Johann define qué necesita; ella agenda con la persona correcta).
|
||
> - Bloqueador vivo: **accesos de Balam** (API BIND, Azure, manual de marca, reglas con Arturo).
|
||
|
||
---
|
||
|
||
## 22 · Jul 1, 2026 — 7:00 AM · Llamada · Kickoff del proyecto ⭐
|
||
|
||
> Participan: Noe Rocha, Pedro Ayala, Erika Chávez y Johann. Canal: Microsoft Teams. Evidencia: `../fuentes/2026-07-01 - Transcript - Kick off-Proyecto integración Balam.txt`.
|
||
|
||
**Resumen:** Arranque formal del MVP. Noé fija la expectativa (plataforma robusta en **menos de 6 meses**, con posible integración futura de **CRM** — "vámonos por partes"). Revisan el GANTT por etapas, el detalle de **accesos**, la **mecánica de horas en Jira** y —el punto más largo— cómo **vincular la factura de la Etapa 0** con el documento contractual.
|
||
|
||
**Acuerdos / decisiones:**
|
||
1. **API BIND (token):** solo **Ara y Arturo** tienen usuario en BIND; se acordó que los tokens salgan de la **cuenta mayor** (todos los permisos habilitados). Para desarrollo se usará el **token de Arturo** (aún sin usar), dejando el de **Ara** para los tableros Power BI. BIND = **1 token por usuario**, no caducable ni múltiple. Se **probará primero el token de Arturo** para confirmar que expone todo lo necesario. Entendimiento: es de **pura consulta** (invoices, facturas, pagos); esta etapa es **solo visualización, sin edición**.
|
||
2. **Manual de marca:** Pedro lo **envía hoy por correo** (paquete de branding). → cumplido, ver [#23](#23--jul-1-2026--733-am--correo--pedro--johann--manual-de-imagen-corporativa).
|
||
3. **Repositorio:** lo **crea Balam / Pedro** (GitHub **privado**) para montar backend/frontend en Fase 1–2. (Antes se preveía que lo montara Johann; ahora lo provee Balam.)
|
||
4. **Azure:** lo gestionan **Pedro + Noé** (Noé otorga permisos donde Pedro tiene limitantes).
|
||
5. **Discovery / proceso actual:** sesión **sí o sí con Arturo y Araceli** (Araceli conoce mejor el proceso; Arturo lleva 3 meses y aún no define todo). **Erika la coordina** (pedirá horas disponibles del equipo).
|
||
6. **Horas / Jira:** Johann reportará sus horas en **Jira** igual que los demás consultores, subiendo incluso material informativo para transparencia. **Pedro le enseñará** el flujo. **Erika hace el corte los lunes** y reporta a dirección al cierre de semana.
|
||
7. **Facturación Etapa 0 = 30 h (tema abierto):** se confirma el monto (**30 h**), pero la **propuesta** dice Etapa 0 = **18–22 h**, lo que el área de pagos/compras cuestionará. Noé necesita que la factura sea **muy vinculante** con un documento. **Acción (Erika + Paola):** revisar si el **contrato** ya ata las 30 h; si no, pedirán por correo a Johann **ajustar la propuesta** para que indique explícitamente las 30 h — **sin etiquetarlo "Etapa 0"** (para no contraponerse con las 18–22 h que figuran arriba; "primer pago por 30 h" abarcaría Etapa 0 + un poco más). Johann **aún no factura**: espera la aclaración/correo para emitir con redacción clara. Balam quiere que ya **corra el plazo de pago** (30 días).
|
||
8. **Conciliación:** sigue de interés; se evaluará **integrarla en esta primera fase** según lo que arroje el Discovery (que definirá **112 vs 136 h** del módulo de facturación). Hoy la hacen 100% manual.
|
||
|
||
**Pendientes que surgieron:**
|
||
- [ ] Balam/Pedro — generar y entregar el **token de Arturo** (BIND) y probar cobertura de endpoints — arranque Discovery.
|
||
- [ ] Balam/Pedro — crear el **repositorio GitHub privado**.
|
||
- [ ] Pedro + Noé — **configurar Azure** y permisos.
|
||
- [ ] Pedro — **enseñar a Johann el flujo de Jira** (reporte de horas).
|
||
- [ ] Erika — **coordinar la sesión de Discovery con Arturo + Araceli** (pedir horas disponibles).
|
||
- [ ] Erika + Paola — revisar si el **contrato vincula las 30 h**; de no ser así, solicitar a Johann por correo el ajuste de la propuesta.
|
||
- [ ] Johann — **no facturar aún**; al recibir el correo, **ajustar la propuesta** (30 h explícitas, sin llamarlo "Etapa 0", **términos comerciales en una sola sección**) y **emitir la factura**.
|
||
|
||
**Citas relevantes:** *"Vámonos por partes, como dice Chuck el destripador."* · *"Necesito que sea muy vinculante al tema del pago con lo que dice el documento… me van a decir ¿dónde dice que son 30 horas?"* · *"Como recomendación, cuando hables de términos comerciales, déjalo en una sola sección."*
|
||
|
||
> **Lectura estratégica:**
|
||
> - El bloqueador ya no es solo "accesos": la **emisión de la primera factura** queda condicionada a que Balam aclare internamente (contrato vs propuesta) y lo pida por correo. Johann hizo bien en **no facturar todavía**; conviene tener lista la versión ajustada de la propuesta para responder rápido cuando llegue el correo.
|
||
> - **Balam asume más de la infraestructura de lo previsto** (crea el repo, gestiona Azure con Pedro/Noé), lo que reduce fricción de accesos para Johann.
|
||
> - **Token de Arturo, solo consulta**: coherente con la estrategia de "lectura primero"; la escritura/emisión se valida en Discovery. Un solo token por usuario refuerza el pendiente de **documentar cuál llave es para qué**.
|
||
> - **Erika = punto único** para agendar la sesión Arturo+Araceli, clave del Discovery. **Jira** pasa a ser obligatorio para el reporte de horas (corte lunes).
|
||
|
||
---
|
||
|
||
## 23 · Jul 1, 2026 — 7:33 AM · Correo · Pedro → Johann · manual de imagen corporativa
|
||
|
||
> **CC:** Noe Rocha, Erika Chávez, Araceli Sánchez. Dirección: recibido. Evidencia (adjunto): `../fuentes/manual de imagen corporativa - Balam.pdf`.
|
||
|
||
**Resumen:** Pedro comparte el **manual de imagen corporativa de Balam** *"para su uso en la herramienta que se desarrollará"*. Sobre el **API de BIND**, indica que buscará a Johann *"en otro momento para ver este tema"* (queda para coordinar por separado). Es el "paquete de branding" que Pedro ofreció en la llamada de hoy ([#22](#22--jul-1-2026--700-am--llamada--kickoff-del-proyecto-)).
|
||
|
||
**Acción derivada:** cierra el pendiente del **manual de marca**. Los tokens (color, tipografía, uso de logo) quedan destilados en [`../marca/Marca-Balam.md`](../marca/Marca-Balam.md) para el **prototipo** de la Etapa 0.
|
||
|
||
**Adjuntos:** `manual de imagen corporativa - Balam.pdf`.
|
||
|
||
> **Nota de marca:** colores oficiales **Amarillo `#F7BD0C`** + **Café `#331F0E`** + Blanco; tipografía **Poppins**. El ámbar `#C0892F` de la propuesta PDF es acento editorial de Johann, distinto del amarillo de marca — para la plataforma se usan los oficiales.
|
||
|
||
---
|
||
|
||
## 24 · Jul 1, 2026 — WhatsApp Erika ↔ Johann · agenda la sesión "Proceso actual de facturación y cobranza" (lunes 6-jul)
|
||
|
||
> Evidencia: `../fuentes/2026-07-01 - WhatsApp - Erika coordinacion sesion facturacion-cobranza.md`.
|
||
|
||
**7:01 AM:** Erika confirma con Johann que ya están en la sesión de kickoff y que se pueda conectar (ver [#22](#22--jul-1-2026--700-am--llamada--kickoff-del-proyecto-)).
|
||
|
||
**1:45–1:46 PM:** Erika pregunta si puede pedir agenda a las **personas involucradas en el proceso de facturación y cobranza** para verlo el **lunes 06 y martes 07 de julio a las 7 am**. Johann da el visto bueno; Erika queda en confirmar por correo.
|
||
|
||
**6:09–6:39 PM:** Erika confirma que le **aceptaron la reunión del lunes 06 a las 7 am** y envía la liga de Teams. Convocatoria: *"Proceso actual de facturación y cobranza- Balam"*, lunes 6-jul 7:00–8:00 AM, organiza Erika, invitados **Johann, Araceli Sánchez Jiménez y Arturo Rosas Hernández** (CC Noe Rocha).
|
||
|
||
> **Lectura estratégica:**
|
||
> - Esta sesión **es** la reunión de Discovery con Arturo + Araceli que Erika se comprometió a coordinar en el kickoff ([#22](#22--jul-1-2026--700-am--llamada--kickoff-del-proyecto-)) — cierra ese pendiente.
|
||
> - Solo quedó confirmado el **lunes 6-jul**; no hay evidencia de que se haya agendado también el **martes 7-jul** mencionado por Erika. A confirmar si hace falta una segunda sesión.
|
||
|
||
---
|
||
|
||
## 25 · Jul 2, 2026 — 4:18–4:41 PM · WhatsApp Erika ↔ Johann · agenda/materiales para la sesión del 6-jul
|
||
|
||
> Evidencia: `../fuentes/2026-07-01 - WhatsApp - Erika coordinacion sesion facturacion-cobranza.md`.
|
||
|
||
Erika pregunta si Johann necesita **algún documento o ejercicio** de parte de Balam para la sesión del lunes, para poder **anticiparlo a los asistentes**. Johann responde con los puntos que propone cubrir:
|
||
|
||
- Proceso de facturación en BIND (PDF/XML), con ejemplos en **USD y MXN**.
|
||
- Revisión de **cobranza y reglas de crédito**.
|
||
- Confirmación de la **"lista blanca" de clientes** (sin recordatorios).
|
||
- Cualquier otro tema operativo que tengan en el radar.
|
||
- Pregunta si **ya tienen el token de BIND** disponible, para poder arrancar con lo técnico.
|
||
|
||
> **Lectura estratégica:**
|
||
> - Johann fija la **agenda de la sesión de Discovery** (#24) antes de que ocurra — mismos temas que venía preguntando desde el 4-may (facturación BIND, cobranza, lista blanca).
|
||
> - Aprovecha el mensaje para **dar seguimiento al token de BIND (de Arturo)**, pendiente desde el kickoff ([#22](#22--jul-1-2026--700-am--llamada--kickoff-del-proyecto-)) — sin respuesta todavía a este punto.
|
||
|
||
---
|
||
|
||
## 26 · Jul 2, 2026 — 5:39 PM · Correo · Johann → Noe (CC Ara, Erika, Pedro) · envío de la propuesta v1.2
|
||
|
||
> **Asunto:** RE: Solicitud de cotización – PRD
|
||
> **Para:** Noe Rocha · **CC:** Araceli Sánchez Jiménez, Erika Chávez, Pedro Alberto Ayala Elizondo
|
||
> Adjunto: `Propuesta-Balam.pdf` (v1.2, 2 MB).
|
||
|
||
*"Buenas tardes a todos, como comentamos en la sesión, les comparto la propuesta actualizada (v1.2, adjunta), donde queda explícita la facturación inicial de 30 horas al arranque del proyecto, con pago a 30 días naturales. Quedo atento a su confirmación para proceder con la emisión de la factura correspondiente. Cualquier comentario o ajuste, con gusto lo revisamos antes."*
|
||
|
||
Johann envía la **propuesta v1.2** (30 h de facturación inicial explícitas, condiciones comerciales consolidadas en §3.3) y queda a la espera de que Balam confirme para poder **emitir la factura**.
|
||
|
||
> **Lectura estratégica:**
|
||
> - Johann **toma la iniciativa**: en el kickoff ([#22](#22--jul-1-2026--700-am--llamada--kickoff-del-proyecto-)) el plan era que Erika+Paola revisaran primero el contrato y, de ser necesario, pidieran por correo el ajuste; en vez de esperar ese correo, Johann ya envió la propuesta ajustada directamente, lo que puede **acelerar el ciclo de la factura**.
|
||
> - Sigue vigente el candado: **no facturar** hasta recibir la confirmación de Balam sobre este correo. Ver [PENDIENTES.md](PENDIENTES.md).
|
||
> - Nota menor: el documento adjunto conserva la frase *"arranque condicionado a contrato u orden de trabajo firmado"* (§3.3 y Próximos pasos), redactada como si la firma estuviera pendiente — cuando el contrato ya se firmó el 26-jun ([#19](#19--jun-26-2026--whatsapp-johann--paola-rh--ajustes-finales-y-firma-del-contrato-)). No debería generar confusión (Balam ya sabe que está firmado), pero queda anotado por si alguien lo señala.
|
||
|
||
---
|
||
|
||
## 27 · Jul 6, 2026 — 7:00 AM · Llamada · Discovery: proceso actual de facturación y cobranza ⭐
|
||
|
||
> Participan: **Araceli Sánchez** (comercial/dirección), **Arturo Rosas Hernández** (administración/facturación), Erika Chávez y Johann. Noé era opcional y no asistió. Canal: Microsoft Teams (~1 h 5 min). Evidencia: `../fuentes/2026-07-06 Proceso actual de facturación y cobranz_ Transcript.txt`.
|
||
|
||
**Resumen:** Primera sesión de Discovery (Etapa 0). Araceli y Arturo muestran en vivo el proceso completo de **facturación**: entrada por **Jira ITSM** (obligatoria desde hace ~1 mes) → validación de administración → **prefactura en BIND** → emisión de CFDI → **envío por correo con particularidades por cliente**. Se demostró el flujo real en BIND (crearon y cancelaron una prefactura en vivo). Dos reglas de negocio cambiaron en la propia sesión. **La parte de cobranza NO se cubrió** — solo se tocaron la lista blanca y la idea de recordatorios; el proceso de seguimiento de pagos queda pendiente de mapear (cuando Johann preguntó si después seguía cobranza, Ara redirigió al proceso de envío de factura).
|
||
|
||
### El proceso actual, paso a paso
|
||
|
||
**1. Entrada — Jira ITSM (portal de servicios interno):**
|
||
- Desde hace ~2 quincenas es **mandatorio**: *"si no hay algo que se levante a través de Jira en un ticket, no se factura"*. Antes se controlaba con un Excel manual → facturas olvidadas (descubrían en marzo que enero no se facturó) y errores de moneda.
|
||
- Módulo *Administración General → Facturación*, con dos tipos: **"Facturación adicional"** (suma) y **"Bajas"** (resta).
|
||
- El portal sirve a **varias empresas** (Balam, Regiotour, Elmstone); el campo "empresa origen" las distingue. A futuro quieren que la plataforma facture también para las demás — por ahora el foco es Balam.
|
||
- **Campos del formulario:** empresa origen · summary · proyecto · **cliente nuevo (sí/no** — si es nuevo se adjunta **cédula de identificación fiscal + cotización**; si es recurrente solo cotización) · moneda (MXN/USD) · **días de crédito** (default 30; a veces 45; CEMEX 90 innegociable) · periodo de incidencias (horas extra, periodos de servicio, comentarios) · **facturación recurrente (sí/no)** + periodo de recurrencia en meses (el equipo de tecnología trabaja en que las recurrencias se detonen solas cierto día).
|
||
- **Quién lo llena:** siempre la parte **comercial = Araceli** (excepcionalmente Pau la apoya). *"El deber ser es que la parte comercial siempre levante el ticket."*
|
||
- **Tres vías generan factura:** (a) ticket directo de facturación adicional; (b) **Headhunting** — el ticket de RH detona automáticamente una factura de anticipo y, al colocar a la persona, el 50% o 100% restante; (c) **Staff augmentation** — al arrancar la persona en el cliente se genera el ticket de factura.
|
||
- **Ruteo:** todos los tickets se asignan por regla a **una sola persona: Arturo**. Administración hace doble check (datos, cédula fiscal, estado de cuenta) sobre la lista.
|
||
- **Flujo interno del ticket con SLAs:** solicitud abierta → proceso de facturación → (espera del colaborador / cancelado) → se adjunta **PDF + XML obligatorios** como evidencia → botón de validación/autorización → estatus **"facturado"**. Flujo alterno de **facturación extranjera**: sin XML, solo la **invoice en PDF** ("validación extranjera").
|
||
|
||
**2. BIND ERP (lo opera Arturo):**
|
||
- Consulta: *Finanzas → Cuentas por cobrar* (facturas en proceso, vencidas, pagadas — ahí dan seguimiento a cobranza).
|
||
- Creación: *Ventas → generar documento*. Siempre hacen **prefactura primero** (no se timbra ante el SAT; cancelar una factura timbrada es retrabajo administrativo y contable) → doble check → **Emitir CFDI**.
|
||
- Prerequisitos que asumen cargados: cliente dado de alta, cuentas, moneda. **Pregunta abierta que dejó Arturo:** definir qué hará la automatización cuando el cliente NO esté dado de alta (proceso aparte).
|
||
- Campos relevantes: sucursal (hoy solo matriz; serviría para facturar por unidad de negocio a futuro) · días de crédito (manual, editable, default del cliente) · orden de compra (deber ser: OC autorizada como prerequisito) · **uso CFDI**: "gastos en general" (nacional) y **"sin efectos fiscales"** (extranjera — se timbra igual pero con **IVA 0%**) · **método de pago PPD/PUE** · conceptos precargados editables (ej. 029 "consultoría y servicios"; sugieren incluir el nombre del recurso) · dirección fiscal precargada · comentarios (ponen el ticket de Jira para cruzar reportes).
|
||
- **⚠️ PPD vs PUE es delicadísimo:** siempre dan crédito → casi todo es **PPD**. Hace ~2 años administración seleccionó PUE por error y les cayó un **requerimiento del SAT**. PUE exige complemento de pago timbrado el mismo día. (Regla de validación clara para la plataforma.)
|
||
- **⚠️ IVA no es automático en BIND:** "sin efectos fiscales"/extranjero debería ir con 0% y pesos con 16%, pero BIND **no lo pone solo** — Arturo lo capturó manualmente (y en el ejemplo puso 16% en una sin efectos fiscales; Ara lo señaló). Otra validación clara para la plataforma. Además, por ser reclutadora a veces llevan retenciones adicionales.
|
||
- Tras la prefactura se habilitan: emitir CFDI, registrar pago, nota de crédito, **editar**, **copiar** (así manejan las recurrencias), cancelar, exportar partidas a Excel, **enviar por email** (a los correos configurados del cliente), descargar PDF, póliza contable.
|
||
|
||
**3. Envío al cliente (el paso que les falta sistematizar):**
|
||
- La facturación "termina" hasta que la factura **se envía por correo**, y cada cliente tiene particularidades: **Axie** (extranjero): facturas + estado de cuenta de todas las facturas · **CEMEX**: factura a un hub + **Excel de horas del colaborador con visto bueno del jefe** + **nomenclatura específica del asunto** (número de proveedor, mes, número de factura en posiciones exactas) y redacción específica del correo · **Dilo** (proyectos): factura + cotización del proyecto · **Acuntia**: .zip + estado de cuenta.
|
||
- Tienen un Excel con cliente → destinatarios; les falta la columna de adjuntos/particularidades. **Ara + Arturo se comprometieron a completarlo y enviarlo HOY (6-jul).**
|
||
- Volumen real: **~55 facturas/mes** de solo **4–6 clientes** — el cliente mayor exige **una factura por colaborador** (~40 colaboradores); agrupadas serían 5–6 facturas.
|
||
|
||
### Dolores (en palabras de Ara, dirección general)
|
||
- El caos de control ya lo mitigó Jira; el dolor vivo es que **el proceso en BIND sigue siendo manual** → errores en montos, descripciones, moneda, IVA, PPD/PUE.
|
||
- No quiere "engrosar la nómina" con capturistas: quiere que la automatización absorba la carga y **enfocar a la gente en actividades de más valor**. El volumen es bajo (~55/mes); el problema es la **incidencia de errores**, y están en franco crecimiento.
|
||
- Reporteo ya lo cubren con Power BI; lo que piden de la plataforma es que **administración solo valide prefacturas** antes del envío.
|
||
- **Dónde quieren la automatización:** después de Jira (confirmado explícitamente por Ara y Arturo cuando Johann lo preguntó). Idea de Arturo: que los agentes **observen Jira** (botones/aprobaciones del flujo) para saber cuándo accionar en BIND.
|
||
|
||
### 🔄 Cambios de reglas de negocio (decididos en la sesión)
|
||
1. **Lista blanca ELIMINADA.** Solo tenían a **Acuntia** (nunca hubo "top 3" reales). Y en la propia llamada **Ara revirtió la decisión**: los recordatorios de morosidad deben ir a **TODOS los clientes, sin excepciones** — hoy arrastran una factura de febrero y otra de abril justamente del cliente "muy pagador" por no recordarle a tiempo. Arturo coincidió: con recordatorios automáticos no habrían llegado a julio con una factura de febrero.
|
||
2. **Cotización en BIND = punto de partida OBLIGATORIO.** Ara lo fijó como requisito formal: *"sí puedes tomar, Johann, como un requisito de que vamos a partir de una cotización del sistema"*. El deber ser: comercial genera la **cotización en BIND** → se adjunta al ticket de Jira → administración (o el agente) la **convierte a prefactura con un clic** → validación humana → CFDI. Para **cliente nuevo**: comercial levanta ticket → administración (que tiene el privilegio) da de alta al cliente en BIND → avisa → comercial ya puede cotizar. No quiere "desarrollo con parchecitos". *(Excepción discutida y descartada: aun en headhunting con rango salarial abierto, la cotización puede esperar al cierre — siempre habrá cotización.)*
|
||
|
||
**Acuerdos / próximos pasos de la sesión:**
|
||
- [ ] **Ara + Arturo** — enviar hoy (6-jul) el **Excel de particularidades de envío por cliente** (destinatarios + adjuntos + nomenclatura).
|
||
- [ ] **Johann** — trabajar el **prototipo** reflejando el flujo real (lo dijo al cierre: *"ya me da una idea más clara de cómo trabajar el prototipo que les mostraré"*). Dudas de seguimiento vía **Erika**.
|
||
|
||
> **Lectura estratégica:**
|
||
> - **El flujo real valida el diseño de la propuesta**: cotización → factura vía API era exactamente el mecanismo cotizado en la Etapa 2, y ahora además es política interna de Balam. El pipeline objetivo queda nítido: **Jira (disparador) → cotización BIND → prefactura → validación humana → CFDI → envío por correo**.
|
||
> - **La eliminación de la lista blanca simplifica el MVP** (el catálogo/lista configurable puede quedar como capacidad, hoy vacía). PERO ojo: lo que Ara y Arturo describen son **recordatorios automáticos a clientes**, que están **diferidos al Anexo B** (el MVP trae alertas *internas*). Su expectativa apunta a ese módulo — conviene aclararlo pronto o anticipar que lo pidan al cierre del MVP.
|
||
> - **Jira como disparador del flujo** (agentes observando tickets/botones) se parece al "Nivel 3" (generación desde eventos) que estaba en fase posterior. La integración con la API de Jira no está cotizada en el MVP — vigilar ese límite de alcance cuando se diseñe el prototipo.
|
||
> - **Se levantaron reglas de validación de oro para la plataforma:** PPD por default (PUE solo consciente — ya les costó un requerimiento del SAT) · IVA 16% MXN / 0% extranjero-sin efectos fiscales (BIND no lo automatiza) · prefactura SIEMPRE antes de timbrar · OC/cotización como prerequisito · alta de cliente como flujo aparte.
|
||
> - **El token de BIND NO se tocó en la sesión** — sigue abierto desde el kickoff y el WhatsApp del 2-jul ([#25](#25--jul-2-2026--418441-pm--whatsapp-erika--johann--agendamateriales-para-la-sesión-del-6-jul)).
|
||
> - **La cobranza quedó sin mapear** — la sesión del **martes 7-jul** (que Erika mencionó desde el 1-jul) sería el espacio natural para cubrirla: cómo dan seguimiento hoy a los pagos, quién persigue morosos, cómo concilian cuentas por cobrar, y de dónde saldría el aging. Proponérselo a Erika.
|
||
> - **Multi-empresa** (Regiotour, Elmstone) aparece como deseo de futuro de Ara — anotarlo para el roadmap, no para el MVP.
|
||
|
||
---
|
||
|
||
## 28 · Jul 6, 2026 — 9:01 AM–12:40 PM · WhatsApp Erika ↔ Johann · token de BIND ENTREGADO ⭐
|
||
|
||
> Evidencia: `../fuentes/2026-07-06 - WhatsApp - Erika sesion discovery y seguimiento token BIND.md`.
|
||
|
||
Tras la sesión de Discovery (7–8 am, [#27](#27--jul-6-2026--700-am--llamada--discovery-proceso-actual-de-facturación-y-cobranza-)), Erika revisa el **plan de actividades** línea por línea:
|
||
|
||
- **9:01** — Sobre *"Entrega y validación de accesos (BIND, Azure, manual de marca) · lun 06 → mar 07 jul"*: *"¿solo necesitas el token tal cual?"* **Johann (9:53–9:54):** *"Sí, para BIND solo necesito el token tal cual. Lo de Azure no me urge hoy y el manual de marca ya lo tengo."*
|
||
- **10:26** — Erika: *"okey deja lo solicito"* → **el token queda formalmente solicitado dentro de Balam.**
|
||
- **10:28–10:37** — Sobre *"Validación técnica de la API de BIND con la cuenta real · mar 07 → mié 08 jul"*: *"¿se necesita una sesión?"* **Johann (10:37):** *"No, esa validación la hago yo por mi cuenta ya teniendo el token."*
|
||
- **12:10–12:19** — **Token GENERADO** dentro de Balam: *"ya solicitaran el token ahorita te lo comparto"*. Erika desconoce si tiene vencimiento (según el kickoff: no caduca), comenta que lo tienen en un **.txt** y pregunta si sirve **por correo**. Johann (12:25): sí, por correo y .txt está bien; (12:27) pide que le confirmen **a qué usuario pertenece** el token para documentarlo.
|
||
- **12:40** — Erika: *"ya se compartió por correo"* → ✅ **TOKEN DE BIND ENTREGADO.**
|
||
|
||
> **Lectura estratégica:**
|
||
> - **El bloqueador del token se resolvió el mismo día:** Johann lo empujó a las 9:01 vía el plan de actividades, Erika lo solicitó a las 10:26 y estaba entregado a las 12:40 — un día antes de la fecha del plan (mar 7-jul). Cierra el seguimiento que venía desde el 2-jul ([#25](#25--jul-2-2026--418441-pm--whatsapp-erika--johann--agendamateriales-para-la-sesión-del-6-jul)).
|
||
> - Que Erika trabaje sobre el plan de actividades confirma que **el Excel de Johann es el instrumento real de seguimiento** — mantenerlo al día paga.
|
||
> - **Quedan dos higienes:** (1) Balam debe confirmar **de qué usuario salió** el token (Johann lo pidió 12:27, Erika "okey" — el acuerdo del kickoff fue el de **Arturo** para dev); (2) tratarlo como **llave de producción** (sin sandbox): guardarlo en gestor de secretos, no dejarlo en el correo/.txt.
|
||
> - **Desbloquea la validación técnica de la API** (mar 7 – mié 8 del plan) — puede incluso adelantarse hoy.
|
||
|
||
---
|
||
|
||
## 29 · Jul 6, 2026 — 12:38 PM · Correo · Pedro → Johann (CC Noe, Erika) · entrega formal del token de BIND ✅
|
||
|
||
> **Adjunto:** `bind_token_api.txt`. Evidencia: `../fuentes/2026-07-06 - Correo - Pedro entrega token BIND (usuario Arturo Rosas).md`.
|
||
|
||
Pedro entrega el **token de la API de BIND** por correo (es el envío que Erika anunció por WhatsApp a las 12:40, [#28](#28--jul-6-2026--901-am1240-pm--whatsapp-erika--johann--token-de-bind-entregado-)) y **confirma que fue generado con el usuario de Arturo Rosas** — conforme al acuerdo del kickoff (llave de Arturo para desarrollo; la de Ara para Power BI). Se ofrece para validar dudas directamente. Erika agradece en el hilo (12:39).
|
||
|
||
> **Lectura estratégica:**
|
||
> - Cierra **las dos puntas** del pendiente de accesos BIND: token entregado **y** usuario documentado. La entrega por correo (no WhatsApp) además deja la evidencia formal en el canal correcto.
|
||
> - Higiene inmediata: pasar el token del `.txt` a un **gestor de secretos** y no conservarlo en el buzón.
|
||
> - Dato colateral: la firma de Pedro lo identifica como **ITSM Analyst / Consultor de Gestión de Servicios TI** — coherente con que él montó el portal Jira ITSM del Discovery.
|
||
|
||
---
|
||
|
||
## 30 · Jul 6, 2026 — 3:01 PM · WhatsApp Johann → Erika · propone sesión de cobranza (martes 7-jul)
|
||
|
||
> Evidencia: `../fuentes/2026-07-06 - WhatsApp - Erika sesion discovery y seguimiento token BIND.md` (bloque 7).
|
||
|
||
Johann plantea a Erika que la sesión de hoy solo alcanzó para **facturación y envío**, y que falta mapear **cobranza** (seguimiento de pagos y cuentas por cobrar). Propone el **martes 7-jul, 7am** — retomando la fecha que Erika misma había mencionado el 1-jul — o cuando se acomode en la semana. **Erika queda en revisar la agenda con las personas involucradas y confirmar.**
|
||
|
||
> **Lectura estratégica:**
|
||
> - Completa el Discovery pendiente de [#27](#27--jul-6-2026--700-am--llamada--discovery-proceso-actual-de-facturación-y-cobranza-) reutilizando la propia propuesta de Erika (bajo costo de coordinación). Interlocutor clave: **Arturo** (lleva CxC en BIND); Ara deseable por el contexto comercial.
|
||
> - Idealmente se confirma antes del **viernes 10** (validación del prototipo), para que la pantalla de Cobranza llegue respaldada por el proceso real y no como hipótesis.
|
||
|
||
---
|
||
|
||
## Resumen ejecutivo del hilo (para contexto rápido)
|
||
|
||
### Datos duros confirmados por Balam
|
||
- **BIND ERP:** API existe y es viable (confirmado 25-may). Límite 20K req/día. PAC para CFDI integrado en BIND.
|
||
- **BUK:** ✅ tiene API (confirmado 27-may por Pedro). No es prioridad para MVP — habilita Fase 2 post-MVP. Link pendiente de recibir.
|
||
- **Bancos:** 3 bancos, solo PDFs. Banco americano = IBC Bank Texas (confirmado en llamada del 19-may).
|
||
- **Sandbox:** solo producción (BIND y BUK).
|
||
- **Volumen:** 45 colaboradores + 5 freelancers, **~55 facturas/mes de 4–6 clientes** (el mayor exige 1 factura por colaborador, ~40) — actualizado 6-jul.
|
||
- **EUR:** fuera del MVP; solo MXN + USD.
|
||
- **Lista blanca cobranza:** ~~ACUNTIA + top 3, configurable~~ → **ELIMINADA (6-jul):** Ara decidió recordatorios a **todos** los clientes morosos, sin excepciones. (La capacidad configurable se conserva, hoy vacía.)
|
||
- **Cotización BIND obligatoria (6-jul):** todo lo que se facture parte de una cotización en el ERP (requisito fijado por Ara).
|
||
- **Flujo actual:** Jira ITSM mandatorio (~1 mes) → validación administración (Arturo) → prefactura BIND → CFDI → envío por correo con particularidades por cliente (Excel pendiente de Ara/Arturo).
|
||
- **Book = SaaS** (no interno).
|
||
- **Jira:** solo gestión de proyectos con clientes.
|
||
- **Nube preferida:** Azure.
|
||
- **Contacto operativo durante MVP:** Noe + gerente administrativo.
|
||
|
||
### Pendientes que Ara (Araceli) debía responder
|
||
- Banco americano específico (resuelto en llamada: IBC Texas).
|
||
- Tax compliance para clientes Texas (resuelto en llamada: estándar).
|
||
- Tickets físicos en pagos con tarjeta.
|
||
- Guía de marca / assets.
|
||
|
||
### Señales clave del CTO
|
||
1. **Llamada del 19-may** (transcript aparte): Noe pidió textualmente *"no le queremos estar poniendo estrellitas al pino, nada más estrictamente lo que se necesita"*. Foco = facturación + conciliación.
|
||
2. **Correo del 25-may**: Noe pide explícitamente que la **propuesta se recorte a "solo ERP BIND" primero**, dejando bancos/conciliación para fase posterior.
|
||
|
||
### Estado actual (al 6-jul-2026 — Discovery en marcha)
|
||
**Contrato FIRMADO (26-jun)**, **kickoff realizado (1-jul)** y **primera sesión de Discovery realizada (6-jul, 7am, con Ara + Arturo — [#27](#27--jul-6-2026--700-am--llamada--discovery-proceso-actual-de-facturación-y-cobranza-)).** El proceso de **facturación** quedó mapeado end-to-end: **Jira ITSM (mandatorio) → validación administración → prefactura BIND → CFDI → envío por correo con particularidades por cliente**. **La cobranza sigue sin mapear** (candidata para la sesión del martes 7-jul). Dos reglas cambiaron en la sesión: **lista blanca eliminada** (recordatorios a todos) y **cotización BIND obligatoria** como inicio del flujo. Ara/Arturo deben enviar hoy el **Excel de particularidades de envío**; Johann trabaja el **prototipo** con el flujo real. **Propuesta v1.2 enviada (2-jul)** — en espera de confirmación de Balam para emitir la factura de 30 h. **Token de BIND sigue pendiente** (no se tocó en la sesión).
|
||
|
||
**Definido en el kickoff:** token **de Arturo** para BIND (solo consulta; se prueba primero) · **Balam crea el repo** (GitHub privado) y **gestiona Azure** (Pedro+Noé) · Johann reporta **horas en Jira** (Pedro le enseña; corte de Erika los lunes) · Discovery **con Arturo + Araceli** (Erika agenda). **Dos bloqueadores vivos:** (1) **accesos** (token BIND, Azure, repo) y (2) **emisión de la 1ª factura** — Johann ya envió la propuesta v1.2 ajustada (2-jul); **no factura hasta que Balam confirme por correo**.
|
||
|
||
**Términos vinculantes del contrato:** sin anticipo + firma previa (cumplida) · **facturación semanal los viernes** por horas efectivamente trabajadas, pago a 30 días · garantía 45 días · alcance MVP BIND-first · arranque condicionado a accesos + API de BIND con lectura/escritura.
|
||
|
||
**Calendario tentativo:** kickoff 1-jul · Etapa 0 (Discovery) sem del 6-jul · Etapa 1 13–24 jul · Etapa 2 27-jul–7-ago · Etapa 3 10–21 ago. Las fechas se confirman/afinan al cerrar el Discovery (dependen de los accesos).
|
||
|
||
**Acciones inmediatas de Johann:**
|
||
- **Asistir al kickoff (1-jul, 7am)** con material listo (agenda + lista de accesos a pedir + preguntas de Discovery).
|
||
- Cambiar régimen fiscal (para facturar) y confirmar permisos exactos de Azure.
|
||
|
||
**En espera de Balam:** entregar **accesos** (API BIND vía cuenta maestra ARA / llave de Arturo, Azure con Guajardo/Erika, manual de marca de Pedro) y reglas de negocio + bancos con Arturo. El **Discovery arranca** una vez recibidos.
|
||
|
||
**Pendiente menor:** (opcional) pedir copia limpia del contrato — la cláusula de Firma Electrónica de la última página quedó duplicada y aún dice "EL PATRÓN" (residuo de plantilla, bajo riesgo).
|
||
|
||
**Conciliación:** sigue como posible primer alcance si el Discovery libera horas (mini-scope + estimación al cierre del Discovery).
|