Resumen ejecutivo
Después de la migración a GCP, el tablero oficial Andesmar se alimenta del schema bi_rebuild. Legacy SAP cumplió otro rol (contabilidad histórica, filas R-). Betterez web muestra un snapshot instantáneo. Ninguno reemplaza a los otros sin definir la pregunta de negocio.
Tres sistemas, tres preguntas
| Sistema | Responde bien | No usar para comparar |
|---|---|---|
| Legacy SAP | Integración contable histórica, filas R- de refund | KPI operativo Betterez 2026; tablero actual |
| GCP public + bi_rebuild | Ventas, estados, montos, tablero MSTR post-migración | Snapshot puntual web sin definir KPI |
| Betterez web / CSV | Lo que el operador ve en pantalla en un instante | Reporting gerencial sin reglas de negocio |
Qué usar para qué
| Necesidad | Fuente recomendada |
|---|---|
| Tablero oficial (pasajes, revenue, agencias) | bi_rebuild.fact_ticket + filtros documentados |
| Auditoría técnica / reconciliación | public + SQL en scripts/reconciliation/ |
| Estado vivo de un boleto hoy | API Betterez (Operations) |
| Comparar con pantalla Betterez por agencia | BI con is_paid_including_partial_cancel, misma agencia y moneda |
| Histórico pre-migración o SAP | Legacy (con corte y definición de fecha documentados) |
Matriz comparativa
| Dimensión | Legacy | GCP public | bi_rebuild | Betterez web |
|---|---|---|---|---|
| Grano boleto | Venta + filas R- | 1 fila por ticket_number | 1 fila = 1 boleto | 1 boleto en UI |
| Fecha de mes | event.created (batch) | sales.sale_date | sale_date heredado | Según reporte |
| Moneda | Solo accountCountry=AR | ARS, CLP, BOB, USD | currency explícita | Según UI |
| Cancel post-venta | No consume ticket.updated | Sí (webhook) | is_paid, effective_ticket_status | Pantalla actual |
| Lag | Corte batch ~21 h | Casi real-time | ETL 2×/día; lookback vía etl_control (prod ~2 d) | Instantáneo |
Por qué GCP supera a Legacy (evidencia)
1. Ciclo de vida del boleto
Legacy no implementa el webhook ticket.updated. Ante refund crea fila R-{ticket} sin actualizar la venta original. GCP actualiza el mismo ticket_number y registra refunds en refund_details.
cancelled en GCP; en Legacy la fila de venta puede seguir paid con R- aparte.2. La brecha de “cancelados”
| KPI ene 2026 | Legacy (crudo) | GCP / BI (curado) |
|---|---|---|
| “Cancelados” | ~1.549 | ~4.700 |
| Boletos totales | ~141.586 | ~141.910 |
La diferencia no son ventas inventadas: es definición y modelo de fila distintos.
3. Montos (comparación correcta)
Legacy SUM(total) venta vs GCP bruto sin filtrar moneda (ARS+CLP+BOB+USD nominal):
| Mes 2026 | Δ bruto | % |
|---|---|---|
| Enero | +31,2M | +0,42% |
| Febrero | +62,1M | +0,98% |
| Marzo | +40,6M | +0,81% |
| Abril | +35,2M | +0,87% |
| Mayo | +23,2M | +0,57% |
currency='ARS' muestra +4% a +7% porque Legacy ya mezcla monedas bajo etiqueta AR.Betterez web: complementarios, no competidores
Betterez web → snapshot del instante: “¿Qué mostró el reporte el día X?”
API Betterez → estado operativo vivo: “¿Este ticket está paid o cancelled ahora?”
bi_rebuild → modelo curado ETL: tablero oficial, rankings, revenue mensual.
Cuándo BI sí puede cuadrar con Betterez web
- Misma agencia (
agency_id/ código) - Mismo eje temporal: sale_date en BI
- Misma métrica:
is_paid_including_partial_cancel = true - Una moneda fija (nunca mezclar ARS+CLP)
- Mismo corte (ETL diario puede ir T+1 en mes en curso)
Ejemplo validado: agencia L78, abr-2026 — 10.935 web = 10.935 is_paid_including_partial_cancel.
Frases listas para reunión
Qué NO afirmar
- No decir “BI mejor que Betterez” sin matizar capa y KPI.
- No comparar Legacy vs GCP filtrando solo ARS.
- No usar Legacy status crudo como cancelados del tablero.
- No sumar montos de monedas distintas en un solo total.
- No auditar junio en curso sin separar lag ETL vs brecha real.
- No usar schema
bilegacy (plural) en tableros nuevos.