JohannVelazquez
cbb29086cc
Consolida el disparador, los huecos de datos y el protocolo de prueba para continuar el desarrollo con decisiones trazables.
108 lines
23 KiB
Markdown
108 lines
23 KiB
Markdown
# PENDIENTES — acciones abiertas
|
||
|
||
Acciones vivas del proyecto. Formato: `[ ]` abierta · `[x]` cerrada (no se borran, dejan rastro). Cada una con responsable y, si aplica, fecha. Ver contexto en [REGISTRO.md](REGISTRO.md).
|
||
|
||
_Última actualización: 2026-08-10 (Balam definió el flujo Jira→BIND en el correo del 7-ago: disparador = `En proceso de facturación`, todos los request types, monto/conceptos como campos de Jira, prueba acompañada sin `FACTEST`. Verificado por API el 10-ago: el campo `Monto sin IVA` ya existe, pero **los conceptos no tienen campo** y **10 de 69 tickets no traen datos estructurados**. Ver [REGISTRO #59](REGISTRO.md))._
|
||
|
||
## 🔥 Flujo Jira→BIND — abierto tras la definición del 7-ago
|
||
|
||
- [x] ~~🔥 **Johann — responder el correo del hilo de Jira**~~ → **Enviado el 10-ago.** Pide ticket de ejemplo, propone mié 12 / jue 13 a las 7:00 am, fija el alcance en la cotización y recuerda Azure. Texto en [REGISTRO #59](REGISTRO.md).
|
||
- [ ] 🔥 **Balam — levantar el TICKET DE EJEMPLO capturado "como debería ser"** (pedido para hoy/mañana en el correo del 10-ago). Tarea **dejada sin asignar a propósito** para que Balam la ruteé; en la práctica es de Arturo. Es el mecanismo elegido para resolver por evidencia, y no por correo, los huecos de abajo. ⚠️ **Riesgo: el precedente de latencia es de 8 días** (pregunta del 30-jul contestada el 7-ago). Si no hay respuesta para mañana al mediodía, empujar por WhatsApp con Erika, que es el canal que responde el mismo día.
|
||
- [ ] 🔥 **Balam/Noé — confirmar la sesión** (mié 12 o jue 13, 7:00 am). Sin fecha confirmada no hay prueba acompañada.
|
||
- [ ] 🔴 **Conceptos/partidas — se resuelve con el ticket de ejemplo.** El acuerdo del 4-ago resolvió el monto (`customfield_11556`) pero **no existe campo de conceptos en todo el sitio de Jira**. Si en el molde el desglose no cabe en ningún campo, hay que agregar uno; si no, la cotización va de una sola línea. **Sigue siendo el único bloqueo real para cerrar B7.**
|
||
- [ ] 🔴 **ACUNTIA — se resuelve con el segundo ticket de ejemplo.** `FAC-100` trae **un solo** `Monto sin IVA` (7,594.00 USD) para el ticket que históricamente representa 40–48 facturas. ¿Un ticket → una cotización? Ver [REGISTRO #55](REGISTRO.md) punto 6.
|
||
- [ ] ⚠️ **Tickets de `Automation for Jira` — convertido en SUPUESTO, ya no bloquea.** 10 de 69 no tienen request type ni un solo campo (incluido `FAC-91`, vivo en validación nacional). En el correo del 10-ago se asienta que **siguen tramitándose a mano** y que la automatización cubre solo los que entran por el portal. Si Balam objeta, la regla de Automation tendría que propagar los campos (trabajo de ellos). El molde capturado a mano no puede resolver esto.
|
||
- [ ] ⚠️ **Johann — decidir el destino de la cotización de la prueba en BIND.** El ejercicio escribe una **cotización real en BIND producción**. Anunciado en el correo, con dos salidas ofrecidas: cancelarla al terminar o apuntarla a un cliente de prueba. Definir cuál antes de la sesión.
|
||
- [ ] 🔴 **¿El comercial ya genera la cotización en BIND, o la genera la plataforma?** Contradicción abierta: el 6-jul Ara dijo que **el comercial la genera y la plataforma la convierte** a prefactura ([REGISTRO #27](REGISTRO.md)); el 4-ago Arturo dijo que **la plataforma la genera**; y el formulario de Jira sigue exigiendo **adjuntar la cotización**. Si ambas cosas ocurren, **quedan dos cotizaciones por ticket**. Se resuelve viendo qué adjunto pone Arturo en el ticket de ejemplo: cotización de BIND ya existente (→ convertir) o documento comercial (→ crear).
|
||
- [x] ~~**Alcance del ejercicio en vivo: ¿cotización o prefactura?**~~ → **Decidido (10-ago): termina en la COTIZACIÓN.** Es lo que contestó Arturo el 4-ago; la aprobación de Araceli va entre `En proceso de facturación` y `Facturado`, así que la prefactura pertenece después; Arturo pidió gradualismo explícito; y la cotización se cancela sin efecto fiscal mientras la prefactura es un registro en `Invoices` con `UUID = null`. La prefactura queda para la segunda sesión. Candados acordados: **cotización → prefactura → aprobación humana → timbrado** ([REGISTRO #55](REGISTRO.md)).
|
||
- [ ] ⚠️ **La transición automática depende de Azure.** En la prueba del miércoles el disparo es **manual** (pipeline `Draft→DryRun→Confirmed` de ADR-001 con flags apagados). Para que corra automática hace falta el ambiente publicado y corriendo continuo — otro argumento para insistir en el acceso a Azure.
|
||
- [ ] 🔥 **Johann — preparar el script contra el ticket de ejemplo** en cuanto Arturo lo levante, para llegar a la sesión con el flujo funcionando. Compartirlo con Balam **antes** de la sesión (protocolo del Bloque 6 de `../planeacion/Investigacion-API-Jira.md`).
|
||
- [ ] **Balam/Noé — fecha para la prueba acompañada de escritura.** Aceptado el formato el 7-ago, sin día propuesto por ellos. En el correo del 10-ago se proponen **mié 12 o jue 13-ago, 7:00 am o después de 6:00 pm** (30 min), sobre un ticket que cree Arturo, con el script compartido de antemano. **No habrá `FACTEST`.**
|
||
- [ ] **Balam — ¿nacional vs extranjero cambia la cotización** o solo el paquete de salida (PDF+XML vs PDF)? Hay dos estatus de validación y una aprobación por rama.
|
||
- [ ] **Balam/Pedro — migrar a cuenta de servicio** en vez de la cuenta personal de Pedro. Planteado el 29-jul, sin respuesta: hoy todo lo que escriba la plataforma queda firmado como Pedro y una rotación suya mata la integración.
|
||
- [ ] **Johann — levantar el sandbox Jira Cloud propio** (plan Free, proyecto JSM que replique el workflow de FAC). Con `FACTEST` descartado, es el único lugar donde se puede equivocar sin costo.
|
||
- [ ] ⚠️ **Johann — implementar la detección por changelog, no por estatus actual.** `FAC-100` estuvo **2m44s** en el estatus disparador; un poller de 15 min que consulte el estado actual se pierde la mayoría de los disparos. Refuerza el caso de pedir un webhook / regla de Automation a Pedro.
|
||
- [ ] **Johann — mover el token de Jira a user-secrets/Key Vault** y borrarlo de disco (ya está en `.gitignore:9`). Mismo pendiente que arrastra `bind_token_api.txt`.
|
||
|
||
## 🔴 Johann (proveedor) — inmediato
|
||
|
||
- [x] ~~**Asistir al kickoff con Noé (mié 1-jul, 7:00 am)**~~ → **Hecho (1-jul).** Ver [REGISTRO #22](REGISTRO.md).
|
||
- [x] ~~📅 **Asistir a la sesión "Proceso actual de facturación y cobranza" (lun 6-jul, 7:00 am)**~~ → **Hecha (6-jul).** Proceso mapeado end-to-end; lista blanca eliminada; cotización BIND obligatoria. Ver [REGISTRO #27](REGISTRO.md).
|
||
- [x] ~~🎨 **Preparar y entregar el prototipo de la Etapa 0**~~ → **Entregado por correo (10-jul)** a Erika + Noé, CC Pedro, con PDF y versión navegable. Refleja facturación, envío, cobranza y reglas del Discovery. Ver [REGISTRO #40](REGISTRO.md).
|
||
- [x] ~~📧 **Enviar por correo el prototipo (imágenes) + comentarios**~~ → **Hecho (10-jul).** Balam respondió que lo revisaría internamente.
|
||
- [x] ~~📊 **Responder a Erika el % de avance de Fase 0**~~ → **Atendido mediante el Excel de avance ajustado y entrega del prototipo.** La validación final sigue abierta.
|
||
- [x] ~~📅 **Preparar y asistir a la sesión de reglas/dudas de Etapa 1 (mié 22-jul)**~~ → **Hecha (22-jul, 7 am):** alta de cliente/proveedor mapeada (Arturo en pantalla), fee = lo registra el despacho (plataforma solo detecta), Jira confirmado en el proceso (estatus final "resuelto"; validación PDF+XML nacional / PDF internacional). No se tocaron particularidades de envío ni PUE/PPD. Ver [REGISTRO #54](REGISTRO.md) y minuta en `../planeacion/Sesion-Etapa1-2026-07-22.md`.
|
||
- [ ] 📅 **Preparar y asistir a la validación del prototipo (jue 23-jul, 7:00 pm).** Llevar decisiones que requieren visto bueno y separar MVP de Anexo B. **Aprovechar para meter la pregunta PUE/PPD que no se alcanzó el 22-jul.** Ver [REGISTRO #42](REGISTRO.md).
|
||
- [x] ~~📊 **Compartir con Erika el corte de avance de la Etapa 1 solicitado el 16-jul**~~ → **Hecho (16-jul, 8:40 pm):** Excel `Plan-actividades-avance-2026-07-16.xlsx` enviado por WhatsApp; Erika acusó recibo ("Ntp, gracias"). Ver [REGISTRO #46](REGISTRO.md).
|
||
- [ ] 📄 **Revisar los procedimientos de carga de facturas por cliente enviados por correo el 16-jul.** Conservar correo/adjuntos como evidencia y contrastar destinatarios, adjuntos, asunto, cuerpo y nomenclatura contra el Discovery y el prototipo. Ver [REGISTRO #46](REGISTRO.md).
|
||
- [x] ~~🔐 **Validar permiso de escritura en el repositorio privado de Balam**~~ → **Comprobado (16-jul):** push exitoso del scaffold inicial (backend .NET 10 + Angular 21, commits `220942a..1f7f098`) a `pedro-balam-itsm/BALAM`. Ver [REGISTRO #46](REGISTRO.md).
|
||
- [ ] ⏱️ **Validar el corte reconstruido de 30 h** en `../planeacion/Seguimiento-horas.csv`: 22 h de Etapa 0 + 8 h de Etapa 1. Solo 3.08 h corresponden a sesiones con duración comprobable; las otras 26.92 h están marcadas como reconstruidas. Ajustarlas si la memoria/evidencia indica otra distribución y después conciliar con Jira. Ver [REGISTRO #45](REGISTRO.md).
|
||
- [ ] 📝 **Cerrar el documento de hallazgos + ADRs** (`../planeacion/Hallazgos-y-decisiones-Etapa0.md`) después de las sesiones del 22–23 jul.
|
||
- [ ] 🔐 **Decidir/aplicar el rol local `balam_app` para que RLS aplique en desarrollo:** la política RLS de B6 está aplicada, pero el usuario `balam` del contenedor es superuser (BYPASSRLS) y la ignora. Falta: `CREATE ROLE balam_app LOGIN NOSUPERUSER NOBYPASSRLS` + `REASSIGN OWNED` + apuntar la cadena de conexión de desarrollo (appsettings.Development y DesignTimeDbContextFactory) a ese rol + repetir la verificación psql. En Azure no existe este hueco (el usuario de app no es superuser). Ver [REGISTRO #53](REGISTRO.md).
|
||
- [ ] ⚠️ **Preguntar a Arturo: ¿por qué TODO el histórico se factura PUE?** 1,374/1,374 facturas con método de pago = PUE, cero PPD, aunque cobran a crédito 30–90 días. Toca la regla "PPD default" de la capa de escritura (B7) y el requerimiento del SAT que ellos mismos sufrieron. **No se alcanzó a preguntar en la sesión del 22-jul** — reintentar el 23-jul (validación del prototipo) o en la sesión de API Jira con Pedro. Ver [REGISTRO #52](REGISTRO.md), [#54](REGISTRO.md).
|
||
- [x] ~~📅 **Proponer a Erika usar la sesión del martes 7-jul para COBRANZA**~~ → **Propuesto (6-jul, 3:01 pm) y CONFIRMADO (6-jul, 6:36 pm):** convocatoria de Teams enviada para el martes 7-jul, 7:00–8:00 am, con Araceli y Arturo (CC Noé). Ver [REGISTRO #34](REGISTRO.md).
|
||
- [x] ~~📅 **Asistir a la sesión de cobranza (mar 7-jul, 7:00 am)**~~ → **Hecha (7-jul).** Sin grabación. Ver [REGISTRO #35](REGISTRO.md).
|
||
- [x] ~~📝 **Documentar el proceso de cobranza** de la sesión del 7-jul (sin grabación)~~ → **Hecho (7-jul):** reconstruido de memoria el mismo día. Notas en `../fuentes/2026-07-07 - Notas - Proceso actual de cobranza (sin grabacion).md`; entrada [REGISTRO #35](REGISTRO.md).
|
||
- [ ] 📊 **Exceles de cobranza (condicional):** si Balam valida que el prototipo representa bien su operación, ya no se requieren. Si pide ajustes, solicitar a Arturo estructura con datos ficticios de abiertas/canceladas/días vencidos, pago↔folio y estado de cuenta. **No confundir con el Excel de particularidades de envío**, que sigue pendiente. Ver [REGISTRO #44](REGISTRO.md).
|
||
- [ ] 🔑 **Dar seguimiento a si Pedro crea el usuario de solo lectura de BIND** que pidió Noé (mientras tanto Erika opera con el usuario de Arturo, sin bloqueo) — sigue sin resolverse una semana después (7-jul). Ver [REGISTRO #37](REGISTRO.md).
|
||
- [x] ~~🔧 **Decidir si probar endpoints de escritura (POST/PUT) de BIND**~~ → **Decidido (7-jul): NO todavía.** Contradice la instrucción de Noé de mantener solo-lectura mientras Pedro confirma el alcance del token; sin sandbox, el riesgo fiscal es real. Alternativa segura: catalogar operaciones de escritura desde el **portal de desarrolladores de BIND** (documentación), no probarlas en vivo. Ver [REGISTRO #36](REGISTRO.md).
|
||
- [x] ~~📧 **Responder el correo de Pedro**~~ → **Enviado (6-jul, ~3:28 pm):** acuse de recibo + usuario de Arturo documentado + arranque de trabajo con la API, sin comprometer entregas adicionales. Ver [REGISTRO #29](REGISTRO.md).
|
||
- [ ] 📧⚠️ **Responder el correo de Noé (importancia alta, 4:33 pm)** describiendo las **salvaguardas** ya operando: solo-lectura bloqueado en código, consultas acotadas, token en gestor de secretos fuera del repo, sin datos reales en documentos, escritura solo con autorización + candados de la propuesta. Borrador listo. **Confirmación informal ya dada por WhatsApp (6-jul, 5:01 pm) — falta la respuesta formal por correo para dejar constancia en el canal correcto.** Ver [REGISTRO #31](REGISTRO.md), [#33](REGISTRO.md).
|
||
- [ ] ⚠️ **No atar nada al token actual:** Pedro está revisando permisos y puede **reemplazarlo** por uno de un usuario nuevo de solo lectura — mantener el token como variable de entorno intercambiable (ya es así en el sandbox). Ver [REGISTRO #31](REGISTRO.md).
|
||
- [x] ~~🔑 **Validar la API de BIND con el token real**~~ → ✅ **Hecha (6-jul, adelantada un día):** 117 peticiones GET-only, Plan A del saldo CONFIRMADO, flujo MVP 100% sostenible en lectura, PDF por API. Hallazgo duro: **sin recurso de pagos/REP**. Documento: [`../bind-api-sandbox/VALIDACION-API.md`](../bind-api-sandbox/VALIDACION-API.md). Ver [REGISTRO #32](REGISTRO.md).
|
||
- [ ] 📨 **Escalar a Pedro las preguntas técnicas de la API** (juntas, esta semana): (1) ¿existe endpoint de **pagos individuales / complementos de pago (REP)** no documentado? — es el hueco más relevante para el flujo PPD, _y ganó caso de negocio el 7-jul: el despacho registra los pagos en BIND uno por uno a mano_; (2) **tabla de mapeo `CFDIUse`** interno → clave SAT; (3) shape del endpoint `/{id}/xml`; (4) ¿webhooks/eventos o solo polling?; (5) ⚠️ **qué token alimenta el Power BI** — el 7-jul Arturo mostró su Power BI conectado con **su** token, pero el kickoff acordó Ara=Power BI / Arturo=desarrollo; BIND emite 1 token por usuario, así que si ambos usos comparten el de Arturo, reemplazarlo por el usuario solo-lectura que planteó Noé rompería uno de los dos. Ver [REGISTRO #32](REGISTRO.md) §10, [#35](REGISTRO.md).
|
||
- [ ] 🔐 **Higiene del token:** moverlo a un gestor de secretos y **borrar `bind_token_api.txt`** de la raíz del repo y del correo/descargas (está gitignoreado, pero sigue en disco).
|
||
- [ ] ⚠️ **Aclarar expectativa de recordatorios a clientes:** lo que Ara/Arturo describieron el 6-jul son recordatorios automáticos **a clientes**, que están **diferidos al Anexo B** (el MVP trae alertas *internas*). Aclararlo pronto o anticipar que pidan ese módulo al cierre del MVP. Igual con la idea de **agentes observando Jira** (Nivel 3, fase posterior) y el deseo **multi-empresa** (Regiotour, Elmstone). **Reapareció el 7-jul:** quieren correos automáticos al cliente pasados 1–5 días de vencimiento ("ser proactivos"). Ver [REGISTRO #27](REGISTRO.md), [#35](REGISTRO.md).
|
||
- [x] ~~**Ajustar la propuesta** (30 h explícitas, sin "Etapa 0", términos comerciales en una sección)~~ → **Hecho (1-jul):** propuesta **v1.2** — se agregó el concepto **"Facturación inicial: 30 h / $18,000 + IVA"** (cubre Etapa 0 + inicio de Etapa 1; Etapa 0 se mantiene en 18–22 h) y se consolidó **§3.3 Condiciones comerciales**. PDF generado y enviado el 2-jul.
|
||
- [x] ~~📧 **Enviar el correo** (Noé, CC Pedro, Ara, Erika) con la propuesta v1.2 ajustada, vinculando la **facturación inicial de 30 h** al acuerdo~~ → **Hecho (2-jul, 5:39 PM):** enviado con `Propuesta-Balam.pdf` adjunto, sin esperar el correo de Erika+Paola. Ver [REGISTRO #26](REGISTRO.md).
|
||
- [ ] 💸 **NO facturar todavía.** Erika confirmó el 13-jul que recibió la propuesta v1.2; la validación para emitir sigue pendiente porque Noé y la CEO están fuera del país. Mantener la factura lista y emitir en cuanto llegue el visto bueno, con pago a 30 días. Ver [REGISTRO #41](REGISTRO.md).
|
||
- [ ] **Configurar Jira y aprender el flujo con Pedro** — reportar horas ahí (incluye material informativo); Erika hace el corte los lunes. Mientras tanto usar `../planeacion/Seguimiento-horas.csv`.
|
||
- [x] ~~Usar los **tokens de marca** en el prototipo~~ → **Hecho:** prototipo y capturas usan Amarillo `#F7BD0C`, Café `#331F0E` y Poppins.
|
||
- [x] ~~Preparar el Excel de actividades~~ → **Entregado y consolidado:** la única versión operativa se conserva en `../planeacion/Plan-actividades-avance-2026-07-10-ajustado.xlsx`; contiene el corte reconstruido de 30 h al 15-jul.
|
||
- [x] ~~Proponer sesiones de Discovery~~ → **Hecho (29-jun):** propuestas y aceptadas; **Erika coordina las agendas** (intermediaria de sesiones).
|
||
- [ ] Cambiar régimen fiscal (en proceso) para poder facturar (CFDI semanal los viernes, pago a 30 días).
|
||
- [x] ~~Confirmar **qué permisos exactos de Azure** necesita~~ → **Definido:** acceso `Contributor` acotado a un grupo de recursos de Balam; no se requiere Global Admin ni una cuenta nueva. Solicitar durante la semana del 21-jul.
|
||
- [x] ~~**Arrancar el Discovery** una vez Balam entregue los accesos~~ → **Hecho (6–7 jul):** facturación, envío y cobranza mapeados.
|
||
- [ ] (Opcional) Pedir a Balam **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). Ver [REGISTRO #19](REGISTRO.md).
|
||
- [x] ~~Revisar y firmar el contrato de servicios~~ → **Hecho (26-jun):** revisado, negociados 2 ajustes (pago de horas al terminar + aceptación a 10 días) y **FIRMADO**. Ver [REGISTRO #18](REGISTRO.md), [#19](REGISTRO.md).
|
||
- [x] ~~Responder el correo de Noe (8-jun)~~ → **Hecho (10-jun):** aceptados los 4 ajustes y respondidas las 3 preguntas técnicas. Ver [REGISTRO #16](REGISTRO.md).
|
||
- [x] ~~Decisión comercial: sin anticipo / pago a 30 días~~ → **Aceptado (10-jun)**, con la condición de **firmar el contrato/orden de trabajo antes de arrancar** (sustituye al anticipo como mecanismo de compromiso).
|
||
- [x] ~~Preparar propuesta v1.1~~ → **Enviada (10-jun)** con los 4 ajustes reflejados. Ver [REGISTRO #16](REGISTRO.md):
|
||
- [x] **Soporte:** bolsa de horas a $600/h, vigencia 12 meses (sin caducidad mensual).
|
||
- [x] **Garantía:** 45 días.
|
||
- [x] **Comercial:** sin anticipo; factura de Etapa 0 + pago a 30 días; avances a 30 días.
|
||
- [x] **Conciliación bancaria:** reflejada como primer alcance condicionado a horas liberadas por el Discovery.
|
||
- [x] **Dashboard/reporteo:** ajustado para no solapar con el tablero Power BI de Pedro (conservar cobranza + alertas).
|
||
|
||
## 🟡 Balam
|
||
|
||
- [x] ~~**Balam:** enviar el documento/contrato de firma~~ → **Hecho (25-jun):** contrato enviado vía Paola (RH); ajustado y **firmado el 26-jun**. Ver [REGISTRO #18](REGISTRO.md), [#19](REGISTRO.md).
|
||
- [ ] 🔑 **Balam: completar accesos de Etapa 1** — token BIND ✅; manual de marca ✅; invitación al repo GitHub recibida y acceso confirmado informalmente (falta validar escritura); Azure programado para semana del 21-jul. Ya no bloquea el desarrollo local, pero Azure sí condiciona despliegue/CI-CD.
|
||
- [x] ~~Erika (PM): pedir el plan de actividades~~ → **Recibido (30-jun).** Erika es la **intermediaria de todas las sesiones**, agendó el **kickoff (1-jul, 7am)** y monta el **tablero Kanban en Jira**. Ver [REGISTRO #21](REGISTRO.md).
|
||
- [x] ~~**Noe:** formalizar por correo~~ → **Hecho:** aclaraciones (8-jun, [#15](REGISTRO.md)) y **luz verde + redacción del documento de firma** (16-jun, [#17](REGISTRO.md)).
|
||
- [ ] **Pedro + Erika:** armar el **tablero de seguimiento en Jira** y revisarlo juntos (instruido formalmente por Noe el 16-jun).
|
||
- [x] ~~**Pedro:** enviar **manual de marca**~~ → **Hecho (1-jul):** enviado por correo. Tokens en [`../marca/Marca-Balam.md`](../marca/Marca-Balam.md). Ver [REGISTRO #23](REGISTRO.md).
|
||
- [x] ~~**Erika:** entregar el **token de BIND**~~ → ✅ **ENTREGADO por correo (6-jul, 12:40 pm)**, mismo día en que se solicitó. Ver [REGISTRO #28](REGISTRO.md).
|
||
- [x] ~~**Balam:** confirmar **a qué usuario pertenece el token**~~ → ✅ **Confirmado (6-jul, 12:38 pm):** Pedro lo entregó por correo (`bind_token_api.txt`) indicando que fue generado con el **usuario de Arturo Rosas** — conforme al kickoff (Arturo=dev, Ara=Power BI). Ver [REGISTRO #29](REGISTRO.md).
|
||
- [ ] **Pedro/Balam:** confirmar permisos de **escritura** para `Johann-28` en el repositorio GitHub privado. Pedro envió la invitación el 15-jul y Johann confirmó acceso el 16-jul; falta una prueba efectiva de escritura. Ver [REGISTRO #43](REGISTRO.md), [#46](REGISTRO.md).
|
||
- [ ] **Pedro:** enseñar a Johann el **flujo de Jira** (reporte de horas como los demás consultores).
|
||
- [ ] **Pedro + Noé:** **configurar Azure** y permisos (Noé otorga donde Pedro tiene limitantes).
|
||
- [x] ~~**Erika:** **coordinar la sesión de Discovery con Arturo + Araceli**~~ → **Hecho:** agendada (1-jul) y **realizada (6-jul, 7am)**. Ver [REGISTRO #24](REGISTRO.md), [#27](REGISTRO.md).
|
||
- [ ] 📊 **Ara + Arturo:** enviar el **Excel de particularidades de envío por cliente** (destinatarios + adjuntos + nomenclatura). Erika confirmó el 13-jul que continúa en preparación y que esperan entregarlo durante la semana. Ver [REGISTRO #41](REGISTRO.md).
|
||
- [ ] **Arturo:** definir el proceso para cuando el **cliente NO esté dado de alta en BIND** — el ASIS del alta ya quedó mapeado en la sesión del 22-jul ([REGISTRO #54](REGISTRO.md)); **sigue abierta la decisión de MVP: ¿la plataforma solo detecta que falta el cliente o también lo crea?** (cruza con la estimación Jira→BIND de ~10 h). Ver [REGISTRO #27](REGISTRO.md), [#51](REGISTRO.md).
|
||
- [ ] 📤 **Arturo/Pedro:** enviar a Johann el **diagrama del flujo Jira de facturación** en tamaño legible (comprometido en la sesión del 22-jul; el screenshot era ilegible). Ver [REGISTRO #54](REGISTRO.md).
|
||
- [ ] 📅 **Erika:** agendar la **sesión con Pedro (+Arturo)** para explorar la **API de Jira** (conexión, campos, webhook), la **facturación recurrente** (~30 facturas/mes) y qué facturas son automáticas vs manuales — acordada en la sesión del 22-jul. Ver [REGISTRO #54](REGISTRO.md).
|
||
- [ ] **Erika + Paola / Noé:** confirmar la propuesta v1.2 para emitir las 30 h. Erika confirmó recepción; validación pendiente por viaje de Noé y CEO. Ver [REGISTRO #41](REGISTRO.md).
|
||
- [ ] **Arturo:** dar acceso/contexto de **bancos** (para conciliación). _Las reglas de negocio de facturación ya quedaron mapeadas en la sesión del 6-jul ([REGISTRO #27](REGISTRO.md)); bancos sigue pendiente._
|
||
|
||
## ⚙️ Acordado (referencia, ya cerrado)
|
||
|
||
- [x] ~~Anticipo de Discovery ($18,000): aprobado (4-jun)~~ → **Corregido (8-jun): Balam NO maneja anticipos.** Se factura la Etapa 0 (30 h) y se paga a 30 días.
|
||
- [x] **Propuesta v1.1 enviada (10-jun) y aceptada por Balam (16-jun).** Balam redacta el documento de firma.
|
||
- [x] **Condición de arranque: contrato/orden de trabajo firmado antes de iniciar** (planteado por Johann 10-jun; aceptado por Balam 16-jun).
|
||
- [x] **Contrato de servicios FIRMADO (26-jun-2026)** por Johann (firma electrónica). Incluye 2 ajustes finales: pago de horas al terminar + aceptación a 10 días naturales. **Facturación semanal (viernes)**, pago a 30 días.
|
||
- [x] **Plan de actividades (4 etapas) entregado** a Erika (29–30 jun). **Kickoff con Noé agendado (1-jul, 7am).** Erika = intermediaria de sesiones; tablero Kanban en Jira.
|
||
- [x] Pagos: **a 30 días** post-factura (incluida la Etapa 0); política firme de Balam (8-jun).
|
||
- [x] Gestión en Jira (ágil, no Gantt); Erika valida entregables (4-jun).
|
||
- [x] Comunicación: canal de WhatsApp + correo para evidencia. Contactos: Erika=principal, Pedro=técnico, Arturo=negocio (4-jun).
|