Cómo está armado el data warehouse

EternumBIS es el data warehouse de Eternum: una base PostgreSQL separada del ERP, pensada para consultar, cruzar y graficar, sin tocar la base de producción.

Está armado en modelo estrella: tablas de hechos con los movimientos, rodeadas de dimensiones con los datos por los que se corta y se agrupa.

Cómo se leen los nombres

Todas las tablas dicen qué son en el prefijo:

Prefijo	Qué es	Cuántas
dim_	Dimensión: por qué se puede cortar o agrupar. Clientes, productos, fechas, depósitos, vendedores.	83
fact_	Hecho: los movimientos. Ventas, compras, remitos, asientos, cobranzas.	45
rel_	Relación: tablas puente entre dos dimensiones, para las jerarquías.	12
tbl_	Tabla del ERP replicada tal cual, sin modelar.	1

En total 141 tablas y 2.759 columnas. El catálogo completo está en las páginas de esta sección.

Las columnas que se repiten en todos lados

Columna	Qué es
id	La clave del registro. En las dimensiones es el mismo código que usás en el ERP.
..._id	Referencia a una dimensión: codemp_id a empresas, fecha_id a fechas, entidad_id a entidades, producto_id a productos. Es por donde se hace el join.
idmodif	Identificador de la última modificación. Es lo que usa el proceso de actualización; en un reporte no se usa.

Empezá siempre por dim_fechas

La dimensión de fechas ya trae los cortes armados: día, semana, mes, bimestre, trimestre, cuatrimestre, semestre y año, cada uno con su identificador combinado (2021-11, 2021-T3, 2021-Q3). Casi ningún reporte necesita calcular períodos: se agrupa por la columna que corresponda.

Es la única tabla con los nombres de columna en inglés; el resto del warehouse está en castellano.

Cómo se actualiza

Un proceso recorre el ERP y trae sólo lo que cambió desde la última corrida. Cada tabla lleva su propia marca de avance, así que la actualización es incremental y no vuelve a leer todo.

Las bajas se replican aparte: el ERP anota lo que se borró y el proceso lo repite en el warehouse.

La ventana de borrados es de cinco días

El proceso sólo mira las bajas de los últimos cinco días. Si el warehouse queda más tiempo sin actualizarse, lo que se borró en el ERP en ese lapso queda en el warehouse: registros que ya no existen y que van a aparecer en los reportes.

No hay ningún aviso. La única forma de limpiarlos es una recarga completa de la tabla. Si el proceso estuvo parado, pedila antes de dar por buenos los números.

La recarga completa vuelve a traer la tabla entera en tandas de 50.000 filas. Desde la versión de septiembre de 2026, si una tanda no se puede cargar el proceso se detiene con un mensaje, en lugar de terminar bien y dejar la tabla vacía o incompleta. Si pasa, hay que volver a pedir la recarga completa de esa tabla.

Si una carga falla, el proceso sigue igual

Las dimensiones se cargan primero, después las relaciones y por último los hechos. Si una dimensión falla, las siguientes se cargan lo mismo, y los hechos quedan con referencias que no resuelven: vas a ver movimientos cuyo cliente o producto aparece vacío al hacer el join.

Ante un reporte con huecos raros, lo primero es revisar si la última corrida terminó bien.

Qué tan al día está

El warehouse no es la base de producción: refleja el estado de la última corrida del proceso. Para números al minuto hay que ir a las consultas del ERP; para análisis, tendencias y tableros, es al revés — el warehouse está para eso.

Consultarlo

Cada tabla y cada columna del warehouse llevan su descripción cargada en la propia base, tomada del ERP. Cualquier herramienta que lea los comentarios de PostgreSQL te los va a mostrar mientras armás la consulta, y son los mismos textos que ves en el catálogo de estas páginas.

Se consulta con cualquier herramienta de reportes o tableros que se conecte a PostgreSQL.

Acceso de sólo lectura

El usuario con el que se consulta el warehouse tiene permisos de lectura. Las tablas se crean y se cargan únicamente desde el proceso: cualquier cambio hecho a mano se pierde en la próxima corrida.

Antes de dar un número por bueno

• Mirá si la tabla que usás es de hechos o de dimensión. Sumar sobre una dimensión no tiene sentido: los importes están en los fact_.
• Cuidado con los estados. Muchos hechos traen el comprobante con su estado y su condición de autorizado: filtralos, o vas a estar sumando cosas que el ERP todavía no considera firmes.
• Los pendientes son foto, no historia. Las tablas de pendientes reflejan el saldo al momento de la corrida. Lo mismo fact_stock_valorizado, que se rehace entera cada vez con el stock y el costo de ese día.
• Cada hecho tiene su grano. Algunos son por comprobante y otros por renglón: fijate si la tabla tiene renglon antes de contar comprobantes.

Ver también

Ver documentación Técnica

• Catálogo de dimensiones — las 83 dimensiones.
• Hechos de ventas
• Hechos de compras
• Hechos de inventarios y producción
• Hechos de finanzas y contabilidad
• Hechos de acopio y hacienda
• Relaciones y tablas auxiliares