Johann
bebca73bfe
Transcript renombrado con fecha, entrada #54 en el REGISTRO, minuta de la sesión llenada, PENDIENTES al día (PUE/PPD y particularidades de envío no se tocaron; nuevos compromisos: diagrama Jira y sesión API con Pedro) y 0.80 h confirmadas en el control de horas. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
105 lines
7.0 KiB
Markdown
105 lines
7.0 KiB
Markdown
# Sesión de reglas y definiciones — Etapa 1
|
||
|
||
**Fecha:** miércoles 22-jul-2026
|
||
**Participantes esperados:** CEO, Arturo, Erika, Johann
|
||
**Objetivo:** cerrar decisiones que afectan el modelo de datos y el alcance técnico antes de implementar escritura e integración Jira→BIND.
|
||
|
||
## Resultado esperado
|
||
|
||
Al terminar deben quedar definidos:
|
||
|
||
1. Flujo de alta de un cliente nuevo.
|
||
2. Tratamiento de diferencias por comisión/fee.
|
||
3. Fuente y reglas de particularidades de envío.
|
||
4. Alcance de la automatización Jira→cotización BIND.
|
||
5. Datos y autorización necesarios para comenzar escritura controlada.
|
||
|
||
## Agenda propuesta (45–60 min)
|
||
|
||
### 1. Alta de cliente nuevo — 10 min
|
||
|
||
- ¿Quién crea actualmente al cliente en BIND?
|
||
- ¿Qué documentos y validaciones son obligatorios?
|
||
- ¿Qué estatus de Jira indica que el alta está autorizada?
|
||
- ¿La plataforma solo debe detectar que falta el cliente o también crearlo?
|
||
- ¿Qué ocurre si el RFC ya existe o los datos fiscales no coinciden?
|
||
|
||
**Decisión a registrar:** alcance exacto del MVP y responsable de cada paso.
|
||
|
||
### 2. Comisión/fee en cobranza — 10 min
|
||
|
||
- Cuando el pago recibido es menor por una comisión, ¿cómo se registra en BIND?
|
||
- ¿Pago parcial con saldo residual, nota de crédito, gasto/comisión o ajuste contable?
|
||
- ¿Existe una tolerancia fija o cambia por cliente/banco?
|
||
- ¿Quién autoriza considerar una factura como saldada con diferencia?
|
||
- 🆕 **Hallazgo del sync histórico (21-jul):** las 1,374 facturas con método de pago registran **PUE — ninguna PPD** — aunque cobran a crédito 30–90 días. ¿Es política deliberada del despacho o práctica a corregir? Impacta la regla "PPD default" de la futura capa de escritura y el requerimiento del SAT que ya sufrieron.
|
||
|
||
**Decisión a registrar:** fórmula de estado de cobranza y si el umbral es global o por cliente.
|
||
|
||
### 3. Particularidades de envío — 10 min
|
||
|
||
- Confirmar destinatarios, adjuntos, nomenclatura del asunto y cuerpo por cliente.
|
||
- Definir quién mantiene estos datos y con qué frecuencia cambian.
|
||
- Confirmar si el Excel en preparación será la fuente inicial para cargarlos.
|
||
|
||
**Decisión a registrar:** estructura mínima del catálogo y responsable de mantenimiento.
|
||
|
||
### 4. Jira → cotización BIND — 15 min
|
||
|
||
Explicar que Jira es parte confirmada del proceso, pero la creación automática de cotizaciones no estaba incluida explícitamente en el alcance inicial.
|
||
|
||
- ¿La expectativa del MVP es solo conservar el folio de Jira o crear automáticamente la cotización en BIND?
|
||
- ¿Qué estatus o aprobación dispara la acción?
|
||
- ¿Qué tipos de ticket aplican: adicional, baja, headhunting, staff augmentation?
|
||
- ¿Qué campos son obligatorios y qué ocurre si falta alguno?
|
||
- ¿Debe haber una previsualización/confirmación humana antes de escribir en BIND?
|
||
|
||
Si Balam confirma la automatización, solicitar posteriormente:
|
||
|
||
- Cuenta técnica de Jira con acceso mínimo al proyecto.
|
||
- API token/OAuth y permiso para webhook o automatización.
|
||
- Identificadores del sitio/proyecto y mapeo de campos.
|
||
- Autorización de escritura controlada en BIND.
|
||
|
||
**Estimación a comunicar (en dos partes, no dar una sola cifra global):**
|
||
|
||
1. *Definición del flujo + accesos:* esta misma semana, un par de horas.
|
||
2. *Desarrollo:* **~10 horas, sujeto a validar la API de escritura de BIND** — sin sandbox, endpoints de escritura no documentados y producción directa (por eso lleva dry-run + confirmación humana). Frase preparada: "La definición del flujo y los accesos los resolvemos esta semana. El desarrollo lo estimo en unas 10 horas, sujeto a lo que encontremos en la API de escritura de BIND, que aún no está documentada y es producción directa — por eso va con dry-run y confirmación humana antes de escribir nada."
|
||
|
||
⚠️ No comprometer el número de desarrollo como cerrado hasta tener las reglas del punto 1 (alta de cliente) — si el ticket puede traer un cliente que no existe en BIND, las dos piezas se tocan y el alcance cambia.
|
||
|
||
**Decisión a registrar:** incluido, diferido o sujeto a estimación/cambio de alcance.
|
||
|
||
### 5. Cierre técnico — 10 min
|
||
|
||
- Confirmar si ya está listo el repositorio GitHub y el acceso de Johann.
|
||
- Confirmar fecha y responsable del acceso Azure.
|
||
- Confirmar cuándo Pedro habilitará el reporte de horas en Jira.
|
||
- Revisar las preguntas técnicas pendientes de BIND: pagos/REP, `CFDIUse`, XML, webhooks y token de Power BI.
|
||
|
||
## Límites que conviene explicitar
|
||
|
||
- Recordatorios automáticos enviados al cliente: Anexo B; el MVP contempla alertas internas.
|
||
- Multiempresa: fuera del MVP; cada empresa requiere token/cuenta BIND.
|
||
- Escritura en producción: solo con autorización, dry-run, confirmación humana y feature flag.
|
||
- Integración Jira automática: pendiente de confirmación de alcance.
|
||
|
||
## Minuta — sesión realizada (22-jul, 7:00 am, ~48 min)
|
||
|
||
> Participaron: Noe (sala), Arturo, Araceli (desde ~min 21), Johann. Erika no estuvo. Transcripción: `../fuentes/2026-07-22 - Flujo para dar de alta clientes nuevos,_ Transcript.txt`. Detalle completo en [REGISTRO #54](../bitacora/REGISTRO.md).
|
||
|
||
| Tema | Decisión | Responsable | Fecha |
|
||
|---|---|---|---|
|
||
| Alta de cliente | ASIS mapeado: mismo flujo clientes/proveedores, 2 pestañas (Detalle + Direcciones), datos de constancia fiscal + estado de cuenta; crédito viene de negociación comercial; extranjeros con RFC genérico y CFDI "sin efectos fiscales" (solo PDF, sin XML). **Pendiente decidir si la plataforma solo detecta o también crea el cliente.** | Arturo demostró; decisión MVP abierta | 22-jul |
|
||
| Fee/comisión | El fee bancario lo registra y deduce **el despacho contable**, no Balam. Solo aplica en pagos internacionales que mueven dinero a México; nacionales cuadran a centavos. La plataforma solo debe **identificar la diferencia como fee** (visible en el estado de cuenta del cliente). | Despacho (asiento) · Plataforma (detección) | 22-jul |
|
||
| Particularidades de envío | **No se tocó.** Excel sigue pendiente de Ara/Arturo. | Ara + Arturo | — |
|
||
| Jira→BIND | Noe confirmó que **Jira ya es parte del proceso** (evolucionó desde el alcance inicial) y puso el ajuste sobre la mesa. Space "Facturación"; estatus final que confirma facturación = **"resuelto"**; validación exige PDF+XML (nacional) o PDF (internacional). Sesión con Pedro para API de Jira + recurrentes. | Erika coordina sesión con Pedro | Por agendar |
|
||
| Escritura BIND | Explorarla con máxima cautela: **no hay sandbox, es producción**. Prueba Jira→cotización será acordada, medida y controlada llegado el momento. | Johann + Noe/Pedro | Tras sesión API Jira |
|
||
| Repo/Azure/Jira horas | **No se tocó.** | — | — |
|
||
| PUE vs PPD (hallazgo 21-jul) | **No se alcanzó a preguntar.** Reintentar el 23-jul o en la sesión con Pedro. | Johann | Pendiente |
|
||
|
||
**Compromisos de Balam salidos de la sesión:**
|
||
1. Enviar a Johann el **diagrama del flujo Jira** en tamaño legible (Arturo/Pedro).
|
||
2. Agendar **sesión con Pedro** (API Jira, facturación recurrente, automáticas vs manuales).
|
||
3. Arturo grabará/documentará los procesos nuevos conforme ocurran (caso Frisa en curso).
|