Finanzas Preguntó si Podían Actualizar Precios sin Abrir un Ticket de Jira. Dijimos que Sí.

Nos miraron como si hubiéramos hecho un milagro.

No fue un milagro. Fue una tabla de input de Sigma conectada a un dbt seed, cuatro columnas con validación por dropdown, y un flujo de trabajo que tardó tres meses en quedar bien. Pero desde la perspectiva del equipo de Finanzas, la experiencia genuinamente fue: abrir dashboard, editar una celda, precios actualizados.

Sin ticket. Sin PR. Sin esperar.

---

El problema del ticket

En una empresa de seguridad en la nube, los cambios de precios requerían que un desarrollador editara macros de SQL. No porque alguien quisiera que fuera así. Simplemente era donde había aterrizado el sistema después de cinco años de crecimiento incremental.

Los primeros macros se veían así:

{% macro calc_node_amount(node_quantity, period, plan_name) %}
case
  when {{ plan_name }} = 'Product-A-tier' and {{ period }} < '2023-04-01' then
    cast([tarifa_v1] as number(38, 9)) * cast({{ node_quantity }} as number(38, 9))
  when {{ plan_name }} = 'Product-A-tier' and {{ period }} < '2024-01-01' then
    cast([tarifa_v2] as number(38, 9)) * cast({{ node_quantity }} as number(38, 9))
  when {{ plan_name }} = 'Product-A-tier' then
    cast([tarifa_v3] as number(38, 9)) * cast({{ node_quantity }} as number(38, 9))
end
{% endmacro %}

Cada cambio de tarifa era un deployment. Cada ajuste de multiplicador regional era un PR. Un incremento del 118% sin documentar había sido aplicado a nivel de base de datos sin ningún registro en git. La lógica de negocio más importante estaba enterrada en macros o era invisible.

Finanzas no podía actualizar nada sin abrir un ticket. Y el equipo de ingeniería estaba atendiendo preguntas de precios cuando tenía infraestructura que mantener.

La historia completa de migrar este codebase cubre la migración técnica. Este post cubre la pieza que llevó a Finanzas de frustrada a completamente autosuficiente: el patrón de tablas de input.

---

La evolución: tres etapas

Pasamos por tres enfoques distintos antes de llegar a algo que Finanzas realmente usaría.

Etapa 1: Macros hardcodeados. Cualquier cambio de tarifa requería tiempo de desarrollador, un PR y un deployment. Cero autoservicio. No viable a largo plazo.

Etapa 2: CSV seed files. Extrajimos todas las tarifas a cinco archivos CSV — precios de producto, multiplicadores regionales, descuentos ELA, descuentos por cuenta, floors trimestrales. Una mejora real. Finanzas podía editar una hoja de cálculo. Pero todavía necesitaban hacer commit a GitHub, lo que implicaba acceso a git y entrenamiento en git. En la práctica, esto significaba que un desarrollador seguía siendo necesario.

Etapa 3: Tablas de input de Sigma. Finanzas edita directamente en el dashboard de Sigma que ya usan. Cero interacción con código. El flujo es: editar en Sigma, solicitar un dbt run, verificar en Sigma. El equipo de ingeniería queda completamente fuera del loop.

Ese último paso — eliminar git del flujo de trabajo — fue la decisión de diseño que hizo que esto funcionara de verdad.

---

Cómo funcionan las tablas de input de Sigma con dbt seeds

Las tablas de input de Sigma te permiten crear superficies editables tipo hoja de cálculo dentro de un dashboard. Los usuarios pueden agregar filas, editar celdas y guardar cambios — todo desde la UI de Sigma. Esos cambios escriben de vuelta a una tabla de Snowflake.

El lado de dbt lee esa tabla como fuente de seed. Cuando el equipo de Finanzas actualiza una tarifa en Sigma y se ejecuta un dbt run, la nueva tarifa fluye automáticamente a través de todo el grafo de modelos downstream.

Aquí está la configuración del seed para la tabla de precios regionales:

seeds:
  - name: regional_pricing_rates
    config:
      schema: pricing
      column_types:
        region: varchar(50)
        percentage_adj: number(5,4)
        effective_date: date
        notes: varchar(255)

Los tipos de columna explícitos importan. Sin ellos, la inferencia de tipos de Snowflake convertirá "1.16" en un entero y truncará ceros iniciales en los IDs de cuenta. Finanzas edita los valores; el contrato de esquema previene corrupción silenciosa.

El modelo dbt que consume este seed usa un patrón de lookup temporal — sin fechas de fin, solo ORDER BY effective_date DESC LIMIT 1 — para que Finanzas pueda agregar nuevas filas para actualizar tarifas sin borrar historial:

-- int_regional_pricing.sql
select
    usage.account_id,
    usage.product,
    usage.billing_period,
    usage.gross_usage,
    rates.percentage_adj as regional_multiplier,
    usage.gross_usage * rates.percentage_adj as adjusted_revenue
from {{ ref('stg_usage') }} usage
left join {{ ref('regional_pricing_rates') }} rates
    on rates.region = usage.region
    and rates.effective_date <= usage.billing_period::date
qualify row_number() over (
    partition by usage.account_id, usage.billing_period
    order by rates.effective_date desc
) = 1

Agregar una nueva tarifa regional en Sigma agrega una nueva fila con un nuevo effective_date. Todos los cálculos históricos quedan sin cambios. Todos los cálculos futuros usan la nueva tarifa. Sin ingenieros involucrados.

---

Validación por dropdown: el detalle que lo hace seguro

Darle a Finanzas una tabla editable sin restricciones sería peor que un CSV — al menos con la revisión del CSV, un ingeniero detectaría un typo antes de que llegara a producción.

La solución es la validación por dropdown. Cada columna que referencia una dimensión — producto, región, plan, cuenta — está restringida a una lista de dropdown en Sigma. Los valores del dropdown se extraen directamente de los datos reales del pipeline.

Siete tablas de dimensiones alimentan la validación:

Estas dimensiones se materializan como tablas y se actualizan automáticamente en cada dbt run. Cuando se lanza un nuevo producto, dim_products se actualiza automáticamente, y el dropdown en Sigma lo refleja en el siguiente run. Sin cambios de configuración requeridos.

Finanzas no puede escribir "us-sout" en lugar de "us-south". No puede ingresar un nombre de plan que no existe. Las tablas de dimensiones hacen cumplir la integridad referencial sin una restricción de base de datos — porque la restricción vive en la UI donde realmente trabajan.

---

El flujo de trabajo de Finanzas: cómo se ve en la práctica

Escribimos una guía de tres capas para el equipo de Finanzas. No un runbook técnico — un flujo de trabajo práctico con comandos de copiar-y-pegar para la única interacción con código que todavía necesitan.

Capa 1 — Referencia rápida:

Capa 2 — Paso a paso (ejemplo: agregar un nuevo descuento de cuenta):

1. Abre Pricing Input Tables en Sigma
2. Navega a la pestaña Account Discounts
3. Agrega una nueva fila: selecciona cuenta del dropdown, selecciona categoría de producto, ingresa porcentaje de descuento, establece fecha de vigencia
4. Guarda
5. Solicita un dbt run (un solo comando, incluido textual en la guía)
6. Abre el dashboard de Account Detail en Sigma y verifica que la nueva tarifa está aplicada

Capa 3 — Queries de validación:

Finanzas puede correr cuatro queries de SQL pre-escritas directamente en Sigma para verificar que sus cambios surtieron efecto:

-- Verificar aplicación de descuento
select
    account_id,
    applied_discount_pct,
    discount_source
from {{ ref('fct_account_discounts') }}
where account_id = '{{ account_id }}'
order by effective_date desc
limit 1

Esto importa más de lo que parece. Antes, Finanzas abría tickets y esperaba a que ingeniería confirmara que la actualización había funcionado. Ahora pueden verificarlo ellos mismos, en la misma herramienta donde hicieron el cambio. El loop de feedback se cerró.

---

Un detalle de timing que Finanzas necesitaba saber

Los modelos mensuales y trimestrales se comportan diferente, y esto confundió al equipo de Finanzas hasta que lo documentamos explícitamente.

Los modelos mensuales incluyen el mes actual de inmediato — un cambio de precios el 15 de marzo aparece en los ingresos de marzo en el siguiente dbt run.

Los modelos trimestrales excluyen el trimestre incompleto actual — un cambio en Q1 no aparecerá en los números de Q1 hasta que Q1 esté completo. Esto es intencional: los trimestres incompletos producen cifras de ARR engañosas.

Sin esta explicación, Finanzas actualizaría una tarifa, correría una validación, no vería ningún cambio en el dashboard de ARR trimestral, y asumiría que algo se rompió. Lo pusimos en la guía con un ejemplo específico. Después de eso, cero confusión.

---

Lo que realmente cambió

Antes de este patrón, el equipo de Finanzas abría tickets de Jira para actualizaciones de precios. Los tickets esperaban en el backlog detrás del trabajo de infraestructura. Un cambio de multiplicador regional para la región de São Paulo — una sola fila en un CSV — podía tardar dos semanas en llegar a producción.

Después: el equipo de Finanzas actualiza precios en Sigma, solicita un dbt run vía Slack, y verifica en el dashboard. De principio a fin, menos de una hora.

El caso de estudio de migración de analytics de ingresos cubre el alcance completo de lo que entregó este proyecto. La capa de autoservicio fue uno de sus resultados, pero el motor de precios subyacente — cómo pasamos de macros hardcodeados a lookups seed-driven — tuvo que construirse primero antes de que el autoservicio de Finanzas fuera siquiera posible.

No puedes darle a Finanzas una interfaz de autoservicio sobre lógica enterrada en macros de Jinja. El modelo de datos tiene que separar los datos de tarifas de la lógica de cálculo antes de que los datos de tarifas puedan hacerse editables. Esa separación es el prerrequisito. Las tablas de input de Sigma son la interfaz encima de ella.