balam/bitacora/PENDIENTES.md

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.

Ú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).

🔥 Flujo Jira→BIND — abierto tras la definición del 7-ago

• 🔥 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.
• 🔥 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 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); 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).
• 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).
• ⚠️ 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

• Asistir al kickoff con Noé (mié 1-jul, 7:00 am) → Hecho (1-jul). Ver REGISTRO #22.
• 📅 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.
• 🎨 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.
• 📧 Enviar por correo el prototipo (imágenes) + comentarios → Hecho (10-jul). Balam respondió que lo revisaría internamente.
• 📊 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.
• 📅 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 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.
• 📊 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.
• 📄 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.
• 🔐 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.
• ⏱️ 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.
• 📝 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.
• ⚠️ 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, #54.
• 📅 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.
• 📅 Asistir a la sesión de cobranza (mar 7-jul, 7:00 am) → Hecha (7-jul). Sin grabación. Ver REGISTRO #35.
• 📝 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.
• 📊 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.
• 🔑 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.
• 🔧 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.
• 📧 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.
• 📧⚠️ 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, #33.
• ⚠️ 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.
• 🔑 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. Ver REGISTRO #32.
• 📨 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 §10, #35.
• 🔐 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, #35.
• 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.
• 📧 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.
• 💸 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.
• 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.
• Usar los tokens de marca en el prototipo → Hecho: prototipo y capturas usan Amarillo #F7BD0C, Café #331F0E y Poppins.
• 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.
• 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).
• 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.
• 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.
• 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, #19.
• Responder el correo de Noe (8-jun) → Hecho (10-jun): aceptados los 4 ajustes y respondidas las 3 preguntas técnicas. Ver REGISTRO #16.
• 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).
• Preparar propuesta v1.1 → Enviada (10-jun) con los 4 ajustes reflejados. Ver REGISTRO #16:
  • Soporte: bolsa de horas a $600/h, vigencia 12 meses (sin caducidad mensual).
  • Garantía: 45 días.
  • Comercial: sin anticipo; factura de Etapa 0 + pago a 30 días; avances a 30 días.
  • Conciliación bancaria: reflejada como primer alcance condicionado a horas liberadas por el Discovery.
  • Dashboard/reporteo: ajustado para no solapar con el tablero Power BI de Pedro (conservar cobranza + alertas).

🟡 Balam

• 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, #19.
• 🔑 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.
• 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.
• Noe: formalizar por correo → Hecho: aclaraciones (8-jun, #15) y luz verde + redacción del documento de firma (16-jun, #17).
• Pedro + Erika: armar el tablero de seguimiento en Jira y revisarlo juntos (instruido formalmente por Noe el 16-jun).
• Pedro: enviar manual de marca → Hecho (1-jul): enviado por correo. Tokens en ../marca/Marca-Balam.md. Ver REGISTRO #23.
• Erika: entregar el token de BIND → ✅ ENTREGADO por correo (6-jul, 12:40 pm), mismo día en que se solicitó. Ver REGISTRO #28.
• 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.
• 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, #46.
• 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).
• Erika: coordinar la sesión de Discovery con Arturo + Araceli → Hecho: agendada (1-jul) y realizada (6-jul, 7am). Ver REGISTRO #24, #27.
• 📊 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.
• 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); 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, #51.
• 📤 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.
• 📅 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.
• 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.
• 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); bancos sigue pendiente.

⚙️ Acordado (referencia, ya cerrado)

• 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.
• Propuesta v1.1 enviada (10-jun) y aceptada por Balam (16-jun). Balam redacta el documento de firma.
• Condición de arranque: contrato/orden de trabajo firmado antes de iniciar (planteado por Johann 10-jun; aceptado por Balam 16-jun).
• 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.
• 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.
• Pagos: a 30 días post-factura (incluida la Etapa 0); política firme de Balam (8-jun).
• Gestión en Jira (ágil, no Gantt); Erika valida entregables (4-jun).
• Comunicación: canal de WhatsApp + correo para evidencia. Contactos: Erika=principal, Pedro=técnico, Arturo=negocio (4-jun).