ANEXO 13

Tablas maestras FARO

Este anexo corresponde a la Fase 4 — Estructura, etapa “Tablas maestras”. Es una de las bases más importantes de FARO Connect, porque define la verdad oficial de la empresa: clientes, productos, empleados, proveedores, sucursales, cuentas, áreas, rubros, roles, canales y centros de costo.

1. Objetivo del anexo

El objetivo de las Tablas Maestras FARO es crear entidades únicas, confiables y reutilizables para que todos los módulos trabajen sobre la misma base.

La pregunta central es:

¿Cuál es la versión oficial de cada cliente, producto, empleado, proveedor, sucursal, cuenta, área o responsable dentro de FARO?

Ejemplo simple:

Sin tabla maestra:
Cliente aparece como:
- Constructora Norte
- Const. Norte
- Obra Norte
- Constructora Norte SA

Con tabla maestra:
CLI_003 — Constructora Norte SA

Sin tablas maestras, FARO puede limpiar datos, pero no puede consolidarlos correctamente.

2. Tesis del Anexo 13

La tesis es:

FARO necesita una única verdad operativa para poder medir, comparar, alertar, asignar responsables y calcular score.

Una empresa desordenada suele tener muchas versiones de lo mismo:

Un mismo producto con cinco nombres.
Un mismo cliente duplicado.
Un proveedor escrito distinto.
Un empleado cargado como vendedor en un Excel y como administrativo en otro.
Una sucursal llamada SJ, San Juan o S. Juan.

FARO debe unificar eso.

Porque si no lo hace:

Las ventas por cliente salen mal.
El margen por producto sale mal.
El stock por sucursal sale mal.
La comisión por vendedor sale mal.
La deuda por cliente sale mal.
El FARO Score sale contaminado.

3. Qué es una tabla maestra

Una tabla maestra es una tabla que contiene las entidades centrales del negocio.

Ejemplo:

Clientes
Productos
Empleados
Proveedores
Sucursales
Áreas
Cuentas
Rubros
Canales
Zonas
Roles
Centros de costo

Cada entidad tiene un identificador único.

Ejemplo:

PROD_001 = CEMENTO_BOLSA_50KG
CLI_003 = Constructora Norte SA
EMP_014 = Juan Pérez
SUC_002 = San Juan
PROV_010 = Proveedor Norte SA

Ese ID único permite cruzar información entre áreas.

4. Diferencia entre alias, normalización y tabla maestra

Ejemplo completo:

RAW:
"Cem x50"

Staging:
"cem x50"

Normalización:
Alias detectado de cemento bolsa 50kg

Tabla maestra:
PROD_001 — CEMENTO_BOLSA_50KG

La tabla maestra es la autoridad final.

5. Tablas maestras mínimas FARO

Una base inicial debería tener entre 8 y 12 tablas maestras mínimas.

En versiones Enterprise o Neural, se pueden sumar:

dim_project
dim_contract
dim_asset
dim_vehicle
dim_industry
dim_process
dim_kpi
dim_tension
dim_action_type
dim_workflow_state

6. Tabla maestra de clientes

6.1 Objetivo

Unificar clientes para medir ventas, margen, cobranza, mora, frecuencia, riesgo y rentabilidad.

6.2 Campos recomendados

6.3 Ejemplo

{
  "customer_id": "CLI_003",
  "legal_name": "Constructora Norte SA",
  "commercial_name": "Obra Norte",
  "tax_id": "30-00000000-0",
  "segment": "Constructora",
  "zone_id": "ZONE_SAN_JUAN",
  "channel_id": "CANAL_OBRA",
  "payment_terms": "30 días",
  "credit_limit": 5000000,
  "risk_level": "medio",
  "profitability_level": "media",
  "status": "activo"
}

6.4 Riesgo si no existe

Clientes duplicados.
Mora mal calculada.
Rentabilidad por cliente incorrecta.
Riesgo financiero invisible.
Ventas por cliente fragmentadas.

7. Tabla maestra de productos

7.1 Objetivo

Unificar productos para medir venta, margen, stock, rotación, quiebres, reposición, compras y rentabilidad.

7.2 Campos recomendados

7.3 Ejemplo

{
  "product_id": "PROD_001",
  "sku": "CEM-50KG-001",
  "normalized_name": "CEMENTO_BOLSA_50KG",
  "brand": "Genérico",
  "category_id": "CAT_CEMENTO",
  "subcategory_id": "SUBCAT_BOLSA",
  "unit": "bolsa",
  "presentation": "50kg",
  "supplier_id": "PROV_010",
  "standard_cost": 6100,
  "list_price": 8500,
  "expected_margin": 0.24,
  "criticality": "alta",
  "rotation_level": "alta",
  "status": "activo"
}

7.4 Riesgo si no existe

El mismo producto aparece como varios productos.
No se calcula margen real.
No se mide rotación correctamente.
No se detecta stock crítico.
No se puede cruzar venta, compra y stock.

8. Tabla maestra de empleados

8.1 Objetivo

Unificar empleados, roles, áreas, sucursales, superiores y esquemas de remuneración para medir productividad, comisiones, ejecución y accountability.

8.2 Campos recomendados

8.3 Ejemplo

{
  "employee_id": "EMP_014",
  "full_name": "Juan Pérez",
  "area_id": "AREA_COMERCIAL",
  "role_id": "ROLE_VENDEDOR",
  "branch_id": "SUC_SAN_JUAN",
  "supervisor_id": "EMP_002",
  "employment_status": "activo",
  "base_salary": 850000,
  "commission_scheme_id": "COMISION_VENTA_MARGEN",
  "raci_profile": "responsable_comercial"
}

8.4 Riesgo si no existe

No se sabe quién vendió.
No se calcula comisión correctamente.
No se asignan acciones con responsable real.
No se mide productividad.
No se puede escalar tareas vencidas.

9. Tabla maestra de proveedores

9.1 Objetivo

Unificar proveedores para medir compras, plazos, cumplimiento, dependencia, precios, riesgo y relación con stock.

9.2 Campos recomendados

9.3 Ejemplo

{
  "supplier_id": "PROV_010",
  "legal_name": "Proveedor Norte SA",
  "tax_id": "30-11111111-1",
  "category_id": "CAT_CEMENTO",
  "average_lead_time_days": 7,
  "compliance_rate": 0.82,
  "dependency_level": "alta",
  "risk_level": "medio",
  "alternative_available": false,
  "status": "activo"
}

9.4 Riesgo si no existe

No se detecta proveedor crítico.
No se mide cumplimiento.
No se anticipan quiebres de stock.
No se analiza dependencia.
No se negocia con información completa.

10. Tabla maestra de sucursales / unidades

10.1 Objetivo

Permitir análisis por sucursal, depósito, local, unidad de negocio o empresa del grupo.

10.2 Campos recomendados

10.3 Ejemplo

{
  "branch_id": "SUC_SAN_JUAN",
  "name": "San Juan",
  "type": "local_y_deposito",
  "city": "San Juan",
  "province": "San Juan",
  "country": "Argentina",
  "manager_id": "EMP_020",
  "status": "en_apertura"
}

10.4 Riesgo si no existe

No se compara desempeño por sucursal.
No se asignan gastos correctamente.
No se mide stock por unidad.
No se calcula score por sucursal.

11. Tabla maestra de áreas

11.1 Objetivo

Definir las áreas FARO sobre las cuales se clasifica la gestión.

11.2 Áreas base

Dirección
Directorio
Comercial
Finanzas
Stock
Compras
RRHH
Operaciones
Administración
Clientes
Proveedores
Sucursales
Sistemas

11.3 Campos recomendados

11.4 Ejemplo

{
  "area_id": "AREA_COMERCIAL",
  "name": "Comercial",
  "parent_area_id": "AREA_DIRECCION",
  "owner_employee_id": "EMP_002",
  "description": "Ventas, margen, clientes, descuentos y objetivos comerciales",
  "active": true
}

12. Tabla maestra de cuentas y centros de costo

12.1 Objetivo

Separar lectura contable de lectura gerencial.

La contabilidad puede decir:

Gastos varios

FARO necesita decir:

Área: Logística
Centro de costo: Distribución
Rubro: Combustible
Responsable: Operaciones

12.2 Tabla de cuentas

12.3 Tabla de centros de costo

12.4 Ejemplo

{
  "cost_center_id": "CC_DIRECTORIO",
  "name": "Directorio",
  "area_id": "AREA_DIRECTORIO",
  "owner_employee_id": "EMP_DIR_001",
  "type": "direccion"
}

13. Tabla maestra de categorías, rubros y subrubros

13.1 Objetivo

Permitir clasificar productos, gastos, compras, reclamos, acciones y tensiones.

13.2 Ejemplo de categorías

13.3 Estructura

{
  "category_id": "CAT_LOGISTICA",
  "name": "Logística",
  "parent_category_id": null,
  "area_id": "AREA_OPERACIONES",
  "type": "gasto_operativo"
}

14. Tabla maestra de canales

14.1 Objetivo

Permitir medir ventas, margen y clientes por canal.

14.2 Canales típicos

Mostrador
Obra
Mayorista
E-commerce
Teléfono
WhatsApp
Vendedor externo
Marketplace
Sucursal
Cuenta corriente

14.3 Ejemplo

{
  "channel_id": "CANAL_OBRA",
  "name": "Obra",
  "description": "Ventas a obras, constructoras o proyectos específicos",
  "area_id": "AREA_COMERCIAL"
}

15. Tabla maestra de zonas

15.1 Objetivo

Permitir análisis territorial.

15.2 Campos recomendados

15.3 Ejemplo

{
  "zone_id": "ZONE_SAN_JUAN",
  "name": "San Juan",
  "province": "San Juan",
  "country": "Argentina",
  "manager_id": "EMP_020"
}

16. Tabla maestra de roles

16.1 Objetivo

Conectar personas con responsabilidades, permisos, workflows y matriz RACI.

16.2 Roles típicos

Gerente General
Gerente Comercial
Responsable de Finanzas
Responsable de Stock
Responsable de Compras
Responsable de RRHH
Responsable de Operaciones
Encargado de sucursal
Vendedor
Cajero
Administrativo
Encargado de depósito
Chofer
Data Owner
Usuario Dirección

16.3 Ejemplo

{
  "role_id": "ROLE_GERENTE_COMERCIAL",
  "name": "Gerente Comercial",
  "area_id": "AREA_COMERCIAL",
  "can_approve_discounts": true,
  "can_view_margin": true,
  "can_assign_actions": true,
  "raci_default": "R"
}

17. Tablas de alias

Las tablas maestras necesitan tablas de alias para resolver nombres alternativos.

17.1 Alias de productos

CREATE TABLE product_alias (
    id UUID PRIMARY KEY,
    product_id TEXT NOT NULL,
    alias TEXT NOT NULL,
    source_id TEXT,
    confidence NUMERIC,
    validated_by TEXT,
    created_at TIMESTAMP DEFAULT now()
);

Ejemplo:

{
  "product_id": "PROD_001",
  "alias": "Cem x50",
  "source_id": "EXCEL_VENTAS",
  "confidence": 0.95,
  "validated_by": "data_admin"
}

17.2 Alias de clientes

CREATE TABLE customer_alias (
    id UUID PRIMARY KEY,
    customer_id TEXT NOT NULL,
    alias TEXT NOT NULL,
    source_id TEXT,
    confidence NUMERIC,
    validated_by TEXT,
    created_at TIMESTAMP DEFAULT now()
);

17.3 Alias de empleados

CREATE TABLE employee_alias (
    id UUID PRIMARY KEY,
    employee_id TEXT NOT NULL,
    alias TEXT NOT NULL,
    source_id TEXT,
    confidence NUMERIC,
    validated_by TEXT,
    created_at TIMESTAMP DEFAULT now()
);

18. Modelo SQL base de tablas maestras

18.1 Productos

CREATE TABLE dim_product (
    product_id TEXT PRIMARY KEY,
    sku TEXT,
    normalized_name TEXT NOT NULL,
    brand TEXT,
    category_id TEXT,
    subcategory_id TEXT,
    unit TEXT,
    presentation TEXT,
    supplier_id TEXT,
    standard_cost NUMERIC,
    list_price NUMERIC,
    expected_margin NUMERIC,
    criticality TEXT,
    rotation_level TEXT,
    status TEXT DEFAULT 'active',
    created_at TIMESTAMP DEFAULT now(),
    updated_at TIMESTAMP DEFAULT now()
);

18.2 Clientes

CREATE TABLE dim_customer (
    customer_id TEXT PRIMARY KEY,
    legal_name TEXT,
    commercial_name TEXT,
    tax_id TEXT,
    segment TEXT,
    zone_id TEXT,
    channel_id TEXT,
    payment_terms TEXT,
    credit_limit NUMERIC,
    risk_level TEXT,
    profitability_level TEXT,
    status TEXT DEFAULT 'active',
    created_at TIMESTAMP DEFAULT now(),
    updated_at TIMESTAMP DEFAULT now()
);

18.3 Empleados

CREATE TABLE dim_employee (
    employee_id TEXT PRIMARY KEY,
    full_name TEXT NOT NULL,
    document_id TEXT,
    area_id TEXT,
    role_id TEXT,
    branch_id TEXT,
    supervisor_id TEXT,
    employment_status TEXT DEFAULT 'active',
    base_salary NUMERIC,
    commission_scheme_id TEXT,
    start_date DATE,
    raci_profile TEXT,
    user_id TEXT,
    created_at TIMESTAMP DEFAULT now(),
    updated_at TIMESTAMP DEFAULT now()
);

18.4 Proveedores

CREATE TABLE dim_supplier (
    supplier_id TEXT PRIMARY KEY,
    legal_name TEXT NOT NULL,
    tax_id TEXT,
    category_id TEXT,
    payment_terms TEXT,
    average_lead_time_days INTEGER,
    compliance_rate NUMERIC,
    dependency_level TEXT,
    risk_level TEXT,
    alternative_available BOOLEAN,
    status TEXT DEFAULT 'active',
    created_at TIMESTAMP DEFAULT now(),
    updated_at TIMESTAMP DEFAULT now()
);

19. Calidad de tablas maestras

Las tablas maestras también deben tener score de calidad.

19.1 Fórmula

Score maestro =
completitud × 30%
+ unicidad × 25%
+ actualización × 15%
+ validación × 15%
+ uso en procesos × 15%

19.2 Código ejemplo

def score_maestro(completitud, unicidad, actualizacion, validacion, uso_procesos):
    return round(
        completitud * 0.30 +
        unicidad * 0.25 +
        actualizacion * 0.15 +
        validacion * 0.15 +
        uso_procesos * 0.15,
        2
    )

19.3 Lectura

20. Gobierno de tablas maestras

Las tablas maestras no pueden quedar libradas a cualquiera.

Regla sana:

Sistemas administra la estructura, pero el área de negocio valida la verdad.

21. Estados de una entidad maestra

22. Resolución de duplicados

22.1 Ejemplo cliente duplicado

CLI_003 — Constructora Norte SA
CLI_088 — Const. Norte
CLI_142 — Obra Norte

Resolución:

Mantener CLI_003 como maestro principal.
Fusionar CLI_088 y CLI_142 como alias.
Mantener histórico de operaciones.
No perder trazabilidad.

22.2 Código conceptual

def fusionar_entidades(entidad_principal, entidades_duplicadas):
    for entidad in entidades_duplicadas:
        reasignar_operaciones(entidad, entidad_principal)
        crear_alias(entidad_principal, entidad)
        marcar_como_fusionada(entidad)

    return {
        "principal": entidad_principal,
        "fusionadas": entidades_duplicadas,
        "status": "fusion_completed"
    }

23. Versionado de maestros

Las tablas maestras cambian.

Ejemplo:

Un producto cambia de proveedor.
Un cliente cambia condición de pago.
Un empleado cambia de sucursal.
Un proveedor pasa a riesgo alto.
Un producto se discontinúa.

FARO debe versionar cambios relevantes.

CREATE TABLE master_data_history (
    id UUID PRIMARY KEY,
    entity_type TEXT NOT NULL,
    entity_id TEXT NOT NULL,
    field_name TEXT NOT NULL,
    previous_value TEXT,
    new_value TEXT,
    changed_by TEXT,
    changed_at TIMESTAMP DEFAULT now(),
    reason TEXT
);

Ejemplo:

{
  "entity_type": "customer",
  "entity_id": "CLI_003",
  "field_name": "risk_level",
  "previous_value": "medio",
  "new_value": "alto",
  "changed_by": "finanzas",
  "reason": "Mora superior a 60 días"
}

24. Relación entre tablas maestras y hechos

Las tablas maestras alimentan las tablas de hechos.

Ejemplo de hechos:

fact_sales
fact_payments
fact_inventory_movements
fact_purchases
fact_expenses
fact_commissions
fact_actions
fact_alerts
fact_tensions

Ejemplo:

SELECT
    s.sale_id,
    c.legal_name AS cliente,
    p.normalized_name AS producto,
    e.full_name AS vendedor,
    b.name AS sucursal,
    s.net_amount,
    s.margin
FROM fact_sales s
JOIN dim_customer c ON s.customer_id = c.customer_id
JOIN dim_product p ON s.product_id = p.product_id
JOIN dim_employee e ON s.employee_id = e.employee_id
JOIN dim_branch b ON s.branch_id = b.branch_id;

Esto permite pasar de registros sueltos a lectura gerencial.

25. Relación con KPIs

Sin tablas maestras, muchos KPIs no son confiables.

26. Relación con tensiones

27. Ejemplo completo: venta con tablas maestras

Dato normalizado

{
  "fecha": "2026-05-27",
  "customer_id": "CLI_003",
  "product_id": "PROD_001",
  "employee_id": "EMP_014",
  "branch_id": "SUC_SAN_JUAN",
  "cantidad": 100,
  "precio_unitario": 8500,
  "descuento": 0.12
}

Cruce con maestros

CLI_003 = Constructora Norte SA
PROD_001 = CEMENTO_BOLSA_50KG
EMP_014 = Juan Pérez
SUC_SAN_JUAN = San Juan

Lectura FARO

Venta de producto crítico de alta rotación,
a cliente constructor,
por vendedor Juan Pérez,
en sucursal San Juan,
con descuento alto,
posible impacto en margen, comisión, stock y cobranza.

28. Ejemplo completo: gasto con tablas maestras

Dato

{
  "descripcion": "OSDE Mayo",
  "monto": 450000,
  "fecha": "2026-05-10",
  "account_id": "ACC_GASTOS_VARIOS"
}

Clasificación con maestros

{
  "area_id": "AREA_DIRECTORIO",
  "cost_center_id": "CC_DIRECTORIO",
  "category_id": "CAT_SALUD_DIRECTORES"
}

Lectura FARO

El gasto corresponde al Directorio.
No debe distorsionar Administración, RRHH ni gastos operativos.

29. Reglas de creación de nuevos maestros

FARO debe definir cuándo se crea una entidad nueva.

Producto nuevo

Crear nuevo producto solo si:
- no existe en maestro,
- no coincide con alias existentes,
- tiene categoría definida,
- tiene unidad definida,
- tiene responsable de validación.

Cliente nuevo

Crear nuevo cliente solo si:
- no existe por CUIT,
- no coincide por razón social,
- no coincide por alias validado,
- tiene segmento y zona mínima.

Proveedor nuevo

Crear nuevo proveedor solo si:
- no existe por CUIT,
- tiene rubro,
- tiene condición de pago,
- tiene responsable de validación.

Código conceptual:

def puede_crear_cliente(cliente):
    if not cliente.get("tax_id") and not cliente.get("legal_name"):
        return False

    if buscar_cliente_existente(cliente):
        return False

    return True

30. Herramientas posibles

31. Riesgos si no existen tablas maestras

32. Output final del Anexo 13

Al finalizar este anexo, FARO debe tener definido:

1. Tablas maestras mínimas.
2. Estructura de clientes.
3. Estructura de productos.
4. Estructura de empleados.
5. Estructura de proveedores.
6. Estructura de sucursales.
7. Estructura de áreas.
8. Estructura de cuentas.
9. Estructura de centros de costo.
10. Estructura de rubros y subrubros.
11. Estructura de canales.
12. Estructura de zonas.
13. Estructura de roles.
14. Tablas de alias.
15. Reglas de creación de nuevos maestros.
16. Reglas de fusión de duplicados.
17. Versionado de cambios.
18. Dueños de negocio por maestro.
19. Score de calidad de maestros.
20. Relación entre maestros, KPIs, tensiones, acciones y FARO Score.

33. Conexión con otros anexos

Las Tablas Maestras FARO definen la verdad oficial de la empresa. Unifican clientes, productos, empleados, proveedores, sucursales, áreas, cuentas, centros de costo y roles para que todos los módulos midan, alerten, asignen acciones y calculen score sobre la misma base. Sin tablas maestras, FARO puede tener datos, pero no tiene una verdad única para dirigir.