Skip to content

Shinkansen · Payouts unificado (vista)

Vista que unifica los payouts (dispersiones) de Shinkansen en una sola tabla: junta lo que llega por webhook (metadata + results) con lo que solo viene por la API de treasury (historia y columnas faltantes). Es la tabla a usar para ver información actualizada de dispersiones.

Es una VIEW temporal, no está en repos ni en dbt (deuda técnica)

shinkansen_payouts_unificado se creó como vista en BigQuery para resolver el mapeo de columnas de un ticket; no vive en ningún repositorio. Martin la dejó como view "hasta cerrar la estructura, después la paso a dbt". Documentada desde el hilo de Slack del equipo de datos (ver Fuentes). Pendiente: migrarla a un modelo dbt versionado.

¿Llegaste hasta acá desde…?

Si ves… Eso sale de… Nota
Dispersiones de Shinkansen "actualizadas" (montos, estado, errores) solvento-data-prod.shinkansen.shinkansen_payouts_unificado Tabla vigente para dispersiones
Shinkansen Transactions History (hasta ~feb 2026) tabla histórica cargada una sola vez ⚠️ No usar para datos actuales — usar la vista unificada
Necesito NRT (near-real-time) las raw shinkansen_metadata / shinkansen_payout_results La vista se refresca 1×/día; para NRT ir a las raw

Resumen

Campo Valor
Qué es VIEW que unifica payouts de Shinkansen (webhook + API treasury)
Tabla solvento-data-prod.shinkansen.shinkansen_payouts_unificado
Refresco ~1 vez al día
Implementación VIEW en BigQuery (sin repo); pendiente migrar a dbt
Para qué Conciliación de dispersiones (Solvento ↔ LoanPro ↔ Shinkansen), auditorías, requerimientos de clientes
Criticidad 🟡 Media
Autor Martin (revisión Oscar Arzate · QA Enya Lucena)

Diagrama

graph LR
    MD[("shinkansen.shinkansen_metadata<br/><i>webhook</i>")]
    RS[("shinkansen.shinkansen_payout_results<br/><i>webhook</i>")]
    TR[["Treasury API Shinkansen<br/><i>historia + columnas faltantes</i>"]]

    V[("shinkansen.shinkansen_payouts_unificado<br/><b>VIEW</b> · refresco ~diario")]
    CONS["Conciliación / auditoría / QA<br/>(dispersiones)"]

    MD --> V
    RS --> V
    TR --> V
    V --> CONS

    classDef store fill:#bfdbfe,stroke:#1e40af,color:#000;
    classDef src fill:#fde68a,stroke:#b45309,color:#000;
    class MD,RS,V store;
    class TR src;

Qué unifica y columnas clave

  • Webhook (NRT) → shinkansen_metadata y shinkansen_payout_results: tracking_key, estado, resultados, cep_receipt_url.
  • API de treasury → Treasury: aporta columnas que no llegan por webhook — amount, description, recipient_account, origin_account — y la historia previa.

Columnas/decisiones de diseño documentadas en el hilo:

  • data_source — indica si la fila se cargó desde API (historia) o desde webhook (metadata + results).
  • origin_account — permite inferir el tenant de origen (Solvento 1 / Solvento 2, es decir SOLVENTO_MX / SOLVENTO2_MX), porque hay una única cuenta bancaria por tenant. La columna source_entity no viene en la respuesta de la API.
  • cep_receipt_url — no viene desde la API, así que queda NULL para la historia cargada por API (sí llega por webhook / proceso CEP).

Si falla / está desactualizada 🛠️

Síntoma Dónde mirar Acción
Dispersiones no actualizadas en la vista Frescura de las raw (shinkansen_metadata, _payout_results) y de la carga de treasury La vista se refresca ~1×/día; revisar los procesos fuente (metadata, results, treasury)
Falta amount/description/*_account Esas columnas vienen de la API de treasury, no del webhook Verificar la corrida de treasury (shinkansen-treasury-api-daily)
cep_receipt_url NULL en filas viejas Esperado para historia cargada por API No es error; por webhook sí llega

Escalación: estructura de la vista / migración a dbt → Martin · dudas de mapeo de columnas → Oscar Arzate.

Pendiente

  • Migrar la vista a dbt (hoy es una VIEW ad-hoc sin repo). Al hacerlo, versionarla y agregar su modelo a dbt-analytics o [dbt-etls].

Enlaces

Fuentes (Slack · #data-team)

Última actualización: 2026-06-21 · Documentada desde Slack (no hay repo). Pendiente migrar a dbt; al hacerlo, actualizar esta ficha.