Construye tu app de reportería comercial y de inventario con Puente OS

0. Qué vas a construir

El problema. Supuesto del ejemplo: en Empresa Demo SpA el equipo comercial arma planillas a mano con ventas del ERP (el sistema donde registras ventas, compras y stock), presupuesto y año anterior. Cada persona calcula distinto. Nadie sabe para cuántos meses alcanza el stock ni cómo cerrará el mes.

El resultado. Una app web con datos que se actualizan cada noche. Responde cinco preguntas:

1. ¿Cuánto vendimos contra el presupuesto y contra el año anterior?
2. ¿Cuánto margen y cuántas unidades dejó esa venta?
3. ¿Cómo va cada mes, semana, día y tienda?
4. ¿Para cuántos meses alcanza el inventario?
5. ¿Cómo cerramos el mes y a qué cliente visito primero?

El mapa de la herramienta.

La app del caso real tiene más de 200 funciones. Esta guía enseña el patrón de cada una. Empieza con tres pasos y crece.

1. Los bloques de Puente OS que vas a usar

Apps. Una app es una página web (hecha con React y TypeScript, tecnologías web estándar) que Puente OS publica con un enlace. No tiene servidor propio y lee y escribe datos por la API de tablas.

Tablas. Una tabla es una base de datos con columnas tipadas: texto, número, fecha, sí o no, y lista de opciones. Una consulta devuelve hasta 5.000 filas por página, así que se pagina. Puente OS no tiene claves foráneas: tú eliges qué columnas de texto unen dos tablas. Una tabla admite columnas nuevas y nunca se borra.

Workflows. Un workflow es una secuencia de nodos que corre sin que nadie abra la app. Se activa por reloj (cron), por webhook o una sola vez. En el caso real, un nodo de código Python lee el ERP y escribe en las tablas. Un webhook es una dirección web que activa el workflow. El webhook síncrono devuelve su respuesta de inmediato.

Integraciones. Una integración conecta un sistema externo: ERP, contador de tráfico, correo, Google Sheets. Un nodo de código llama cualquier API. Toda conexión con credenciales vive en un workflow (capítulo 3).

Agentes. Un agente es un asistente de IA que ejecuta tareas con herramientas. El caso real no los usa.

Los límites de plataforma de esta guía se observaron en una app real. Confírmalos en tu cuenta.

2. Antes de construir, levanta tu proceso

2.1 Cuestionario de 12 preguntas

Responde por escrito. Cada respuesta fija una decisión, o perilla, que ajustas según tu empresa. La última columna indica dónde se toma.

2.2 Cómo elegir por dónde empezar

Puntúa cada módulo del 1 al 5 en dos columnas: cuánto duele hoy y cuántos otros módulos necesita. Puntaje = duele − necesita. Empieza por el mayor. Ante un empate, elige el que usa menos tablas.

El paso 1 y el paso 2 son la base en cualquier empresa. El resumen ejecutivo (paso 5) y el inventario (paso 6) comparten la foto de cierre de stock. Si construyes el paso 5 primero, construye también esa tabla y su carga.

Paso 1 · Tus tablas y la carga nocturna

Qué resuelve. Define dónde viven los datos y cómo llegan cada noche.

Qué construyes. Las tablas del modelo de datos genérico (empieza por las universales) y un workflow nocturno que las llena.

Una tabla por pregunta, a su grano

El grano es el nivel de detalle de una fila. Define el grano antes de crear la tabla. Una tabla angosta responde más rápido. El caso real tiene varias tablas de ventas con granos distintos.

Modelo de datos genérico

Las columnas van separadas por tipo. fecha es de tipo fecha. Columna "Uso": U = universal, O = opcional.

Reglas de las tablas

1. Períodos como números. Guarda fecha y repite ano, mes, dia y semana ISO como números. La app filtra sin calcular.
2. Año en cada tabla de presupuesto. El caso real no lo tiene, y por eso el presupuesto solo existe para un año. La app apaga la comparación en otros años. Agrega ano desde el inicio.
3. Cálculos que la consulta no hace. La consulta solo suma y cuenta. No multiplica una columna por otra. Guarda precalculado lo que necesites multiplicar (lista_total, margen).
4. Equivalencias de nombres. El ERP escribe el mismo nombre de varias formas. La tabla de equivalencias traduce cada grafía a su forma oficial, y todas las cargas la leen.
5. Cruces por texto exacto. Presupuesto y venta se unen por canal, tienda y marca. Un nombre distinto deja una fila huérfana.
6. Agrega columnas a la tabla existente. En el caso real se creó una segunda versión de una tabla por ignorar esto, y la tabla vieja quedó para siempre.

La carga nocturna

Cómo funciona. Un workflow con cron (programación por reloj) corre de madrugada, cuando el ERP está libre.

1. Calcula la ventana: desde hoy − N días hasta ayer.
2. Busca los «días sucios»: documentos creados o anulados con fecha anterior a la ventana. Si existen, alarga la ventana hasta el más antiguo, con un tope.
3. Lee del ERP solo la ventana. Aplica exclusiones y equivalencias.
4. Por cada tabla destino: lee lo existente, compara por contenido, borra lo que sobra e inserta lo que falta.
5. Devuelve un resumen con el conteo por tabla.

Ejemplo. Hoy es 15 de octubre y la ventana de 30 días va del 15 de septiembre al 14 de octubre. Una tienda anuló una factura del 2 de septiembre. El paso 2 de la receta alarga la ventana hasta esa fecha. Sin él, septiembre quedaría distinto del ERP.

Por qué se diseñó así.

• Ventana móvil con comparación por contenido. Una ventana de 60 días superó el tiempo de ejecución y se bajó a 30. Comparar antes de escribir evita reescribir filas iguales.
• Salvaguarda contra lecturas vacías. Protege cada tabla: si la fuente devuelve cero filas, conserva la tabla. Una falla de conexión la vaciaría.
• Fallas aisladas. Las tablas opcionales van en bloques propios. Si el contador de tráfico cae, las ventas ya quedaron escritas.

Cómo lo adaptas. Largo de la ventana, tope de días sucios, horario del cron y exclusiones. Presupuesto y tiendas comparables se cargan desde una planilla.

Cómo verificas. Elige un mes cerrado. Suma la venta neta en tu ERP y en la tabla de ventas diarias. Deben coincidir al peso. Repite con un mes que tuvo anulaciones.

La app muestra en su encabezado la hora de la última carga ("Carga nocturna: 15-oct-2026 03:00 · venta hasta el 14-oct"). Así cualquiera sabe hasta qué día llegan las cifras.

Paso 2 · Ventas contra presupuesto y año anterior

Qué resuelve. Muestra cuánto se vendió contra el presupuesto y contra el año anterior.

Qué construyes.

• Tablas: ventas diarias, ventas por producto, presupuesto mensual, tiendas comparables.
• Vista: cuatro tarjetas (ingreso, unidades, contribución, margen %). Agrega un gráfico mensual contra año anterior y presupuesto, un acumulado, una torta por canal y barras por categoría y marca.
• Opcional: un árbol categoría ▸ marca ▸ familia ▸ producto, que pide los productos al abrir cada familia.

Cómo funciona.

• Variación = (venta ÷ venta del año anterior − 1) × 100.
• El año anterior se corta en la misma fecha que el año actual (ayer).
• Con filtro de mes, el acumulado corta en ese mes. Sin filtro de mes, el presupuesto es el anual completo.
• Si la comparación pierde sentido (año sin presupuesto, vendedor o tienda sin presupuesto), la tarjeta muestra "--".
• El filtro de tiendas comparables limita venta, año anterior y presupuesto al mismo conjunto de tiendas. Si deja la vista en cero, se apaga solo.

Ejemplo. Hoy es 15 de octubre. Empresa Demo SpA vendió $9.800.000 del 1 de enero al 14 de octubre. El año anterior, hasta el 14 de octubre, vendió $8.750.000. Variación: +12,0 %. Si la app comparara con el año anterior completo ($10.600.000), mostraría −7,5 %, una caída falsa. El presupuesto anual es $14.000.000: el avance es 70 %.

Por qué se diseñó así.

1. Una sola función decide la ventana de tiempo de venta, año anterior y presupuesto. Cuando cada lado la calculaba aparte, uno miraba 1 día y otro 7.
2. El corte del año anterior va dentro de la consulta. Parchear cada gráfico repitió errores.
3. Tablas precalculadas como camino principal. La tabla agregada responde en menos de un segundo. La tabla general de presupuesto tardaba entre 5 y 20 segundos.

Cómo lo adaptas. Presupuesto anual o a la fecha. Corte del año anterior en ayer o en el último mes cerrado.

Cómo verificas. Fija un mes cerrado. Compara las cuatro tarjetas con una consulta directa al ERP. Elige un año sin presupuesto: aparece "--".

Paso 3 · Margen y unidades

Qué resuelve. Muestra cuánto margen deja cada categoría, tienda y producto, y cuántas unidades se mueven.

Qué construyes.

• Tablas: las del paso 2. El costo presupuestado sale del presupuesto mensual con tienda y costo.
• Vistas: dos pestañas con las tarjetas del paso 2. Margen agrega los diez productos que más contribuyen. Unidades agrega los diez más vendidos y las marcas que superaron el año anterior.

Cómo funciona.

• Contribución = venta neta − costo. Margen % = contribución ÷ venta neta × 100.
• Los porcentajes de un total se recalculan con sumas.
• Una consulta agrupada de más de 5.000 filas se pide por páginas. El orden incluye todas las columnas del agrupado.

Ejemplo. Una categoría vendió $1.000 con costo $640: contribución $360, margen 36,0 %. El año anterior tuvo 33,0 %: variación +3,0 puntos. Dos tiendas: una vende $100 con margen 50 % y otra $900 con margen 20 %. El promedio simple da 35 %. El margen real es (50 + 180) ÷ 1.000 = 23 %.

Por qué se diseñó así.

1. Ratios sobre sumas. Un promedio de porcentajes pesa igual a una tienda chica y a una grande.
2. Los diez mejores salen de la tabla por producto. Es liviana. A cambio, esa lista ignora los filtros de canal, tienda, vendedor, semana y día. Dilo en pantalla.

Cómo lo adaptas. Tamaño del ranking. Sugerencias sin probar: costo con o sin gastos indirectos, umbral de color del margen.

Cómo verificas. Suma las contribuciones de todas las categorías. Debe igualar la tarjeta. Cambia un filtro dos veces seguidas: la pantalla debe mostrar el último.

Paso 4 · Resumen por mes, semana y día

Qué resuelve. Entrega una matriz de períodos o de tiendas con venta, unidades, contribución, ticket, tráfico y conversión. Reemplaza la planilla manual.

Qué construyes.

• Tablas: ventas diarias, presupuesto mensual y diario, boletas por día, tráfico mensual, tiendas comparables.
• Vista: selectores de grano (mes, semana, día) y de filas (período o tienda), tarjetas y matriz.

Cómo funciona.

• Ticket = venta ÷ boletas. UPT (unidades por boleta) = unidades ÷ boletas. Conversión = boletas ÷ entradas de público, sobre las mismas tiendas y meses.
• Tráfico y conversión existen solo en el grano mensual: el contador entrega meses. En semana y día se apagan.
• Con venta o unidades netas menores o iguales a cero, ticket y UPT quedan en blanco: dominan las devoluciones.
• En semana y día, el año anterior usa el día equivalente: fecha menos 364 días.
• Con filtro de categoría, marca o vendedor se apagan los indicadores por boleta.
• Los períodos futuros muestran presupuesto y año anterior, sin venta ni variación.

Ejemplo. En octubre la Tienda Norte vendió $2.400.000 con 800 boletas y 2.000 unidades: ticket $3.000, UPT 2,5. Con 4.000 entradas en el mes, la conversión es 20 %. El miércoles 14 de octubre de 2026 se compara con el miércoles 15 de octubre de 2025. Un mes con $3.000.000 de presupuesto da $100.000 por día si se prorratea parejo. La planilla real asigna $180.000 a un sábado.

Por qué se diseñó así.

1. Presupuesto diario real. El equipo compara contra su planilla diaria, y el prorrateo parejo se alejaba de ella. Las unidades siguen prorrateadas: la fuente no las tiene por día.
2. Día equivalente en semana y día. En el comercio pesa el día de la semana. El mes y las tarjetas anuales siguen el calendario.
3. Mismo universo en cada ratio y comparación. Boletas y entradas usan las mismas tiendas y meses. Las tiendas comparables limitan venta, año anterior y presupuesto al mismo conjunto. Comparar venta cero con el presupuesto en el futuro daría −100 %.

Cómo lo adaptas. Día equivalente o fecha calendario. Curva diaria o prorrateo. Tráfico y conversión solo con contador.

Cómo verificas. Suma las filas por tienda de un tramo. Venta y año anterior deben dar el total de la matriz (el presupuesto del total puede diferir). Abre un domingo del año en curso y comprueba que compara con el domingo equivalente.

Paso 5 · Resumen ejecutivo del cierre

Qué resuelve. Entrega la foto del mes cerrado por canal, tienda, cliente y marca.

Qué construyes.

• Tablas: ventas diarias, presupuesto mensual, foto de cierre de stock (con su carga mensual, que el paso 6 reutiliza), boletas, tráfico, ventas por cliente.
• Vista: selector de mes de cierre, filtro de marca y cuatro tablas (por canal, tu canal propio, tu canal mayorista por cliente y por marca).

Cómo funciona.

• Meta = presupuesto del mes completo. Variación contra meta = (venta ÷ meta − 1) × 100.
• MOI (meses de inventario) = valor del stock al cierre ÷ costo de venta del mes.
• MOS (meses de stock) = valor del stock al cierre ÷ costo presupuestado promedio de los 3 meses siguientes.
• En noviembre el MOS promedia solo diciembre. Solo existe para el año que tiene presupuesto.
• Color: menos de 1 rojo, menos de 3 ámbar, 3 o más verde.

Ejemplo. Al cierre de septiembre el stock vale $1.200.000 a costo y el costo de venta del mes fue $400.000: MOI = 3,0 (verde). El costo presupuestado de octubre a diciembre es $1.500.000, o $500.000 por mes: MOS = 2,4 (ámbar). En diciembre no hay meses siguientes y el MOS queda vacío.

Por qué se diseñó así.

1. Foto congelada del stock. Al mirar septiembre, el stock es el del 30 de septiembre.
2. El stock sin canal sigue en el total. Se oculta de la tabla por canal a pedido del negocio. El total de la empresa lo conserva.

Cómo lo adaptas. Ventana del MOS, costo o unidades, umbrales de color.

Cómo verificas. Calcula a mano el MOI de un canal con el stock de tu ERP al último día de un mes cerrado. Si el mes no tuvo movimientos nuevos, una nueva foto de cierre da el mismo valor.

Paso 6 · Inventario y cobertura

Qué resuelve. Muestra el stock por categoría, marca, familia y producto, y cuántos meses de venta cubre.

Qué construyes.

• Tablas: stock actual, stock por almacén y canal (solo para la cobertura), foto de cierre, maestro de artículos, ventas por producto y tienda, presupuesto mensual y por producto.
• Vista: un árbol de unas 16 columnas (venta, año anterior, unidades, contribución, presupuesto, stock, valor, MOI, MOS).
• Un buscador de producto y un panel de stock por almacén, que lee el maestro ancho. Una descarga del maestro.

Cómo funciona.

• El árbol carga filas agregadas. Los productos de una familia se piden al abrirla.
• MOI = costo del stock ÷ costo de venta mensual de los 3 meses cerrados anteriores. Con foto de cierre, usa el costo de venta del mes.
• MOS = costo del stock ÷ costo presupuestado mensual de los 3 meses siguientes.
• Una bodega compartida atiende a varios canales. Al filtrar por canal, el stock se muestra completo. El MOI y el MOS usan solo la parte de ese canal. Esa parte = costo de venta del canal ÷ costo de venta de todos los canales de la bodega.

Ejemplo. La bodega central tiene $600.000 de stock a costo. Atiende al Canal A (costo de venta anual $300.000) y al Canal B ($100.000). El Canal A usa 75 %: $450.000. El Canal B usa 25 %: $150.000. Sin reparto, el MOI del Canal B sería cuatro veces más alto.

Por qué se diseñó así.

1. Árbol agregado y productos bajo demanda. Unas 600 filas cargan en unos 2 segundos. Los productos esperan a que se abra su familia.
2. Stock completo en pantalla y reparto solo en la cobertura. Acuerdo con el negocio: el stock real se muestra completo y el reparto solo corrige la cobertura.
3. El panel por almacén sale de una tabla ancha. Una fila por producto y una columna por almacén. La tabla por almacén y canal repite la bodega compartida en cada canal y triplica su stock al sumar. Por eso solo sirve a la cobertura.

Cómo lo adaptas. Meses de la ventana, costo o unidades, criterio del reparto.

Cómo verificas. Suma el valor del stock de las filas de nivel superior: debe igualar tu ERP. Filtra los canales de una bodega compartida: sus partes suman el costo total de la bodega.

Paso 7 · Seguimiento comercial con proyección de cierre

Qué resuelve. Compara meta y venta por canal, proyecta cómo cierra el mes e indica a qué cliente visitar primero.

Qué construyes.

• Tablas: ventas diarias, presupuesto mensual, pedidos abiertos, cliente y marca, captura manual.
• Vista A, por canal: Meta, Margen y Real por mes, el acumulado del año (YTD) y el mes en curso con Empuje y Cierre proyectado.
• Vista B, por cliente y marca: Meta anual, mensual y acumulada, venta real, cumplimiento, cuánto venderle y prioridad.
• Workflow de guardado del Empuje, con ruta fija: borra, inserta y registra quién cambió.

Cómo funciona.

• Cierre proyectado = Real del mes + Pedidos abiertos + Empuje.
• Empuje es lo que una persona estima vender además de lo anterior. Se teclea por fila y los totales suman sus filas.
• Cumplimiento del mes = Cierre proyectado ÷ Meta del mes × 100.
• Meta mensual = Meta anual ÷ 12. Cuánto venderle = el mayor entre 0 y (Meta acumulada, que incluye el mes en curso, − Real de los meses cerrados).
• Cumplimiento (vista B) = Real de los meses cerrados ÷ (Meta mensual × meses cerrados) × 100.
• Prioridad = 1 + clientes de la misma marca con un "cuánto venderle" mayor.

Ejemplo. El Canal Mayorista tiene meta mensual de $1.000.000. Al día 14 lleva $520.000, con pedidos abiertos por $180.000 y un Empuje de $150.000. Cierre proyectado = 520 + 180 + 150 = $850.000. Cumplimiento: 85 %. Vista B: el Cliente A con la Marca X tiene meta anual $1.200.000 y mensual $100.000. Su meta acumulada a octubre es $1.000.000 y vendió $780.000 hasta septiembre. Cuánto venderle: $220.000. Cumplimiento: 780 ÷ 900 = 86,7 %.

Por qué se diseñó así.

1. Replica la planilla que el equipo ya usa. Cada fórmula se verificó contra el archivo.
2. El cierre se calcula y el Empuje se teclea. Así funciona la planilla.
3. Guardar reemplaza la fila. La API de tablas con clave no actualiza una fila: hay que borrar la anterior e insertar la nueva. Variante recomendada: el guardado pasa por un workflow con ruta fija que hace ambos pasos. Si dejas la escritura directa desde la app, anótala como excepción (capítulo 4, punto 5). Después limpia la caché (copia temporal) para que el valor no desaparezca al releer.

Cómo lo adaptas. Componentes del cierre (con o sin pedidos abiertos), mes editable, reemplazo o historial. Meta mensual plana (anual ÷ 12) o real mes a mes.

Cómo verificas. Teclea un Empuje y recarga la página. El valor sigue ahí, con una sola fila en la tabla de captura. Borra el valor y comprueba que la fila desaparece.

Paso 8 · Documentos de venta

Qué resuelve. Permite buscar una boleta o factura por su folio y ver cada línea con su precio y margen.

Qué construyes.

• Tabla: una fila por línea de documento, solo para los canales donde importa (por ejemplo, tu canal de tiendas propias).
• Vista: caja de búsqueda, tres vistas (Documento, Detalle, Producto), totales de la selección, filtro de margen negativo y ventana con la boleta completa.

Cómo funciona.

• Una búsqueda de solo dígitos busca el folio exacto. Si no existe, busca un tramo de código de producto. Otro texto busca por contenido.
• La paginación ocurre en el servidor: 100 filas por página. El orden incluye todas las columnas del agrupado de cada vista, más desempates. Verifícalo en cada vista.
• Margen % = (venta neta − costo) ÷ venta neta. Descuento = lista − pagado, con lista que incluye impuesto y pagado = venta neta × (1 + impuesto).

Ejemplo. El folio 4821 tiene 2 unidades. Lista con impuesto: $23.800. Venta neta sin impuesto: $17.000. Costo: $12.000. Con IVA de 19 %, pagado = 17.000 × 1,19 = $20.230. Descuento = 23.800 − 20.230 = $3.570, o 15,0 %. Margen = 5.000 ÷ 17.000 = 29,4 %. Precio neto: $8.500 por unidad.

Por qué se diseñó así.

1. Lista total y margen precalculados en la carga. La consulta no multiplica columnas.
2. Paginación en el servidor. El navegador recibe 100 filas.
3. Folio como búsqueda principal. El folio impreso es numérico. En el caso real ningún código de producto tiene solo dígitos. Confirma lo mismo en tu catálogo.

Cómo lo adaptas. Documento tributario, impuesto, canales incluidos.

Cómo verificas. Busca una boleta impresa por su folio: el total pagado coincide con el papel. Busca un folio inexistente: aparece un mensaje claro.

Paso 9 · Exportación

Qué resuelve. Entrega la información en un archivo CSV para analizarla en una planilla.

Qué construyes.

• Un botón de descarga en las vistas que lo necesiten.
• Un control de cuadre en la descarga más grande, con tolerancia mínima. Incluye una revisión de productos repetidos.

Cómo funciona.

• Cada fila del CSV es un registro plano, sin subtotales ni porcentajes.
• La línea 1 trae los encabezados. Sin título, notas ni filas extra.
• Los números llevan coma decimal. El archivo lleva marca BOM para que la planilla lea las tildes.
• Una celda de texto que empieza con =, +, - o @ recibe un apóstrofo delante. Así la planilla no la ejecuta como fórmula.
• Las tablas grandes se piden en páginas de 5.000 filas. Cada descarga tiene su tope.
• Control de cuadre: antes de entregar el archivo, la app suma cada columna y la compara con el total de la pantalla.

Ejemplo. El detalle por producto tiene 3.200 filas y su venta suma $9.800.000, igual que la pantalla: se entrega. Con $9.790.000, la descarga falla.

En la app de demostración, el botón Descargar CSV está al pie de la pestaña Ventas (ver la imagen del paso 2). Junto al botón, la app confirma cuántas filas bajó y que el total cuadra con la pantalla.

Por qué se diseñó así.

1. CSV plano. Una tabla dinámica suma o promedia mal los subtotales y porcentajes.
2. Sin metadatos. Las filas extra rompían las tablas dinámicas.
3. Un archivo que no cuadra no se entrega. Un archivo erróneo destruye la confianza en todo el reporte.

Cómo lo adaptas. Separador, formato decimal, tope por descarga.

Cómo verificas. Abre el archivo en tu planilla y crea una tabla dinámica. La suma de la venta iguala el total de la pantalla.

3. Conecta tus sistemas externos

3.1 El patrón: el workflow como proxy seguro

La app lee las tablas. El workflow habla con el sistema externo y escribe en las tablas. Hay tres razones:

1. El navegador no abre conexiones a bases de datos. Un ERP sobre SQL Server u otra base pide una conexión directa, que solo un servidor abre.
2. El secreto queda en el servidor. Todo lo que viaja al navegador es público.
3. Cuota de terceros. Un proveedor con una consulta diaria se agota si cada usuario lo llama desde su navegador.

3.2 Sistemas del caso, por función

3.3 Reglas por tipo de conexión

ERP. Usa una cuenta de solo lectura. Lee sin bloquear tablas. Pasa los filtros del usuario como parámetros y nunca pegados al texto de la consulta. Documenta las reglas de la consulta: exclusiones, descuentos, notas de crédito.

Contador de tráfico. Cuida la cuota diaria del proveedor. El proveedor corrige su historial: recarga el año en curso cada noche. Pon esta carga en un bloque propio y mantén un mapa de cada contador a su tienda.

Correo y PDF. El workflow genera el informe, lo guarda en una tabla de una fila y envía el enlace. Una URL firmada vence (en el caso real, a las 8 horas): adjunta el PDF o avisa. Prueba el PDF con tus tildes.

3.4 Variantes por país

Elige zona horaria local si el disparador la acepta. Con UTC (hora universal), la hora local de la carga se desplaza dos veces al año. Elige una ventana con holgura.

4. Seguridad y publicación

1. Permisos mínimos. La app lee. Si tu cuenta ofrece credenciales de solo lectura, úsalas. La captura manual del paso 7 escribe por un workflow con ruta fija. Una escritura directa es una excepción (punto 5). Los workflows de carga usan otra credencial, que vive en el servidor.
2. Lo que ve el navegador es público. Una app compartida por enlace entrega todo su código. Una credencial de escritura dentro de la app permite que cualquiera escriba en tus tablas.
3. Los secretos viven en el servidor. Guarda cada clave en un solo lugar. Nunca pegues credenciales en un documento o un chat. Fija la versión de cada librería del workflow.
4. Datos personales fuera de las tablas públicas. Nombres de vendedores y clientes, comentarios libres e identificadores tributarios no deben llegar a una tabla que lee una app pública.
5. Escritura desde la app, con cuidado. Una captura manual directa desde el navegador la puede usar cualquiera con el enlace. Borrar e insertar en dos llamadas carece de atomicidad: si falla la segunda, el valor anterior se pierde. Lo mejor es una escritura por workflow, con ruta fija y registro de quién cambió qué.
6. Cargas que no se rompen en silencio. Borrar todo y luego insertar deja la tabla vacía durante la corrida: compara por contenido. Protege cada tabla contra una lectura vacía: si la fuente devuelve cero filas, conserva la tabla. Haz que el workflow falle de forma visible. Si falta un dato secundario, avisa en pantalla.
7. Verifica que el cron corre. Revisa la primera ejecución al día siguiente. En el caso real, tres cargas pasaron cuatro semanas sin correr porque su programación nunca se registró. Cada semana, revisa la fecha de la última fila de cada tabla.
8. Apaga lo que no se usa. Un workflow de respaldo con acciones que nadie llama sigue expuesto. El del caso ofrecía 6 acciones y la app usaba 2. Cuando entra en acción, muestra cifras con reglas distintas, sin avisar. Apaga las acciones sin uso. Avisa en pantalla cuando el respaldo esté activo. Una carga sin lector gasta cuota.
9. Publica con método. Construye con datos de prueba, compara cada cifra con el ERP y deja que un solo responsable publique.

5. Adáptalo a tu empresa

5.1 Tabla de perillas

5.2 Variantes por tamaño e industria

Las variables de país (impuesto, documento, moneda, horario) están en 3.4.

6. Checklist final y glosario

6.1 Checklist

• Respondí las 12 preguntas del cuestionario.
• Cada tabla tiene su grano, dueño y lector anotados, y la de presupuesto lleva columna de año.
• La carga tiene ventana móvil, días sucios con tope y comparación por contenido.
• La carga protege cada tabla contra una lectura vacía y aísla las tablas opcionales.
• Cada módulo pasó la prueba de su sección "Cómo verificas".
• Una comparación muestra "--" cuando falta la base.
• La app usa una credencial de solo lectura. La captura manual pasa por un workflow, o queda anotada como excepción. Ninguna credencial de escritura está en el código de la app.
• Apagué los workflows y las cargas sin uso.

6.2 Glosario