ANEXO 8

Fuentes e ingesta de datos

Este anexo corresponde a la Fase 1 — Captura, especialmente a las etapas “Fuentes de datos” e “Ingesta de datos” de la tabla maestra FARO Connect. En la tabla, esta fase busca identificar dónde vive la información real de la empresa, traerla hacia FARO y definir reglas de frecuencia, origen, trazabilidad y conexión.

1. Objetivo del anexo

El objetivo del Anexo 8 — Fuentes e ingesta es definir desde dónde obtiene información FARO Connect, cómo la recibe, con qué frecuencia, con qué nivel de confiabilidad y bajo qué método técnico.

FARO Connect necesita poder tomar información desde:

ERP
Excel
Google Sheets
CRM
POS
Bancos
WhatsApp
Mails
PDFs
APIs
Formularios
Sistemas internos
E-commerce
Marketplaces
Sistemas de stock
Sistemas de RRHH
Herramientas de tareas

La pregunta central de este anexo es:

¿Cómo entra la información a FARO Connect de forma ordenada, trazable y utilizable?

Porque FARO no puede detectar KPIs, alertas, tensiones o acciones si primero no sabe qué dato entra, de dónde viene, quién lo envió y qué tan confiable es.

2. Tesis del Anexo 8

La tesis es:

FARO Connect no reemplaza todos los sistemas existentes desde el día uno. Primero los conecta, los ordena y los convierte en una fuente de dirección.

Una empresa normalmente ya tiene sistemas. El problema es que están desconectados:

El ERP factura.
El Excel calcula comisiones.
El banco muestra caja.
WhatsApp tiene pedidos.
Stock tiene movimientos.
RRHH tiene sueldos.
Dirección tiene decisiones en reuniones.

FARO Connect debe actuar como una capa superior de integración ejecutiva.

No arranca destruyendo lo que existe. Primero conecta, interpreta y ordena. Después, si corresponde, mejora procesos.

3. Diferencia entre fuente, ingesta e integración

Ejemplo simple:

Fuente:
Excel de ventas.

Ingesta:
Carga manual semanal.

Integración:
FARO lee columnas, valida datos y guarda RAW.

Resultado:
Ventas disponibles para KPIs comerciales.

4. Tipos de fuentes de datos

4.1 Fuentes internas estructuradas

Son las mejores para empezar porque ya tienen formato relativamente ordenado.

4.2 Fuentes internas semiestructuradas

Tienen datos útiles, pero suelen venir con problemas.

4.3 Fuentes externas

Pueden enriquecer el análisis.

5. Mapa FARO de fuentes por área

6. Métodos de ingesta

FARO debe soportar distintos métodos, porque no todas las empresas tienen el mismo nivel tecnológico.

6.1 Carga manual

Sirve para MVP, empresas desordenadas o primeras pruebas.

Usuario carga Excel / CSV / PDF.
FARO valida estructura.
FARO guarda RAW.
FARO limpia y normaliza.

Ventaja:

Rápido para arrancar.

Riesgo:

Depende de disciplina humana.

6.2 Carga programada

FARO importa datos en horarios definidos.

Todos los días a las 22:00.
Cada lunes a las 08:00.
Último día del mes.

Ejemplo técnico:

from apscheduler.schedulers.background import BackgroundScheduler

scheduler = BackgroundScheduler()

def importar_ventas_diarias():
    print("Importando ventas desde ERP...")

scheduler.add_job(importar_ventas_diarias, "cron", hour=22, minute=0)
scheduler.start()

6.3 Conexión por API

Ideal cuando el sistema origen permite conexión.

FARO consulta API.
Recibe JSON.
Guarda RAW.
Procesa datos.

Ejemplo:

import requests

def obtener_ventas(api_url, token):
    headers = {"Authorization": f"Bearer {token}"}
    response = requests.get(f"{api_url}/ventas", headers=headers)
    response.raise_for_status()
    return response.json()

6.4 Webhook

La fuente avisa a FARO cuando pasa algo.

Ejemplo:

Nueva venta.
Nuevo cobro.
Nuevo pedido.
Nuevo reclamo.
Nueva tarea.

Ejemplo FastAPI:

from fastapi import FastAPI, Request

app = FastAPI()

@app.post("/webhook/venta")
async def recibir_venta(request: Request):
    payload = await request.json()

    # Guardar RAW
    raw_event = {
        "source": "erp",
        "event_type": "venta_creada",
        "payload": payload
    }

    return {"status": "received", "event": raw_event["event_type"]}

6.5 Conectores ETL / ELT

Para conectar muchas fuentes con menor desarrollo.

Herramientas posibles:

Airbyte
Fivetran
n8n
Make
Zapier
Meltano
Conectores propios

Uso típico:

ERP → Airbyte → Base FARO
Banco → n8n → FARO
Google Sheets → API → FARO

6.6 Extracción desde documentos

Para PDFs, facturas, remitos o contratos.

Flujo:

Documento
→ extracción de texto
→ identificación de campos
→ validación
→ RAW
→ staging
→ normalización

Campos posibles:

número de factura
fecha
proveedor
CUIT
importe
IVA
producto
cantidad
condición de pago

6.7 Ingesta desde WhatsApp o mails

No conviene prometer automatización total de entrada. Pero sí puede estructurarse gradualmente.

Ejemplo:

Mensaje WhatsApp:
“Necesito 100 bolsas de cemento para mañana, cliente Obra Norte.”

FARO puede extraer:
cliente = Obra Norte
producto = cemento
cantidad = 100
fecha requerida = mañana
tipo = pedido

Ejemplo conceptual:

def extraer_pedido_mensaje(texto):
    return {
        "tipo": "pedido",
        "cliente_detectado": "Obra Norte" if "Obra Norte" in texto else None,
        "producto_detectado": "cemento" if "cemento" in texto.lower() else None,
        "cantidad_detectada": 100 if "100" in texto else None
    }

Esto debe validarse antes de entrar al modelo ejecutivo. Si no, WhatsApp se transforma en una licuadora de datos.

7. Frecuencias de ingesta

No todos los datos necesitan actualizarse con la misma frecuencia.

8. Priorización de fuentes a conectar

No conviene conectar todo de golpe. Hay que priorizar.

Fórmula sugerida

Prioridad de fuente =
Impacto ejecutivo × 30%
+ Calidad del dato × 20%
+ Facilidad de conexión × 20%
+ Frecuencia de uso × 15%
+ Relación con tensiones críticas × 15%

Ejemplo en código:

def prioridad_fuente(impacto, calidad, facilidad, frecuencia, relacion_tensiones):
    score = (
        impacto * 0.30 +
        calidad * 0.20 +
        facilidad * 0.20 +
        frecuencia * 0.15 +
        relacion_tensiones * 0.15
    )

    if score >= 80:
        return "conectar_primero"
    elif score >= 60:
        return "conectar_fase_2"
    elif score >= 40:
        return "conectar_mas_adelante"
    return "no_prioritaria"

9. Matriz de priorización inicial

10. Estructura de una fuente FARO

Cada fuente debe registrarse como un objeto formal.

{
  "source_id": "ERP_VENTAS_001",
  "nombre": "ERP - Ventas",
  "tipo": "ERP",
  "area": "Comercial",
  "owner": "Sistemas",
  "responsable_negocio": "Gerente Comercial",
  "frecuencia": "diaria",
  "metodo_ingesta": "API",
  "formato": "JSON",
  "nivel_confianza": "medio",
  "campos_principales": [
    "fecha",
    "cliente",
    "producto",
    "cantidad",
    "precio",
    "descuento",
    "vendedor"
  ],
  "kpis_habilitados": [
    "ventas_netas",
    "descuento_promedio",
    "ticket_promedio"
  ],
  "riesgos": [
    "costo_unitario_no_disponible",
    "cliente_duplicado"
  ]
}

11. Metadata obligatoria por ingesta

Cada carga debe tener metadata. Sin eso no hay trazabilidad.

Ejemplo:

{
  "load_id": "LOAD_2026_05_27_001",
  "source": "excel_ventas",
  "uploaded_by": "administracion",
  "uploaded_at": "2026-05-27T22:00:00",
  "company_id": "COMP_001",
  "branch_id": "SUC_001",
  "records_received": 1200,
  "records_valid": 1140,
  "records_observed": 60,
  "status": "processed_with_observations"
}

12. Estados de una ingesta

13. Pipeline de ingesta FARO

La ingesta debe seguir un flujo controlado.

Fuente
→ Recepción
→ Registro de metadata
→ Guardado RAW
→ Validación inicial
→ Control de calidad
→ Staging
→ Normalización
→ Tablas maestras
→ Modelo ejecutivo
→ KPIs / reglas / tensiones

Ejemplo conceptual:

def pipeline_ingesta(payload, fuente):
    load_id = registrar_metadata(fuente, payload)
    guardar_raw(load_id, payload)

    errores = validar_payload(payload)

    if errores:
        marcar_observado(load_id, errores)
    else:
        marcar_aceptado(load_id)

    staging = transformar_a_staging(payload)
    normalizado = normalizar(staging)
    integrar_modelo_ejecutivo(normalizado)

    return {
        "load_id": load_id,
        "status": "procesado",
        "errores": errores
    }

14. Validación inicial de ingesta

Antes de procesar, FARO debe validar mínimos.

Ejemplo: ventas

Campos mínimos:

fecha
cliente
producto
cantidad
precio
vendedor
sucursal

Validación:

def validar_venta_raw(registro):
    errores = []

    campos_obligatorios = [
        "fecha",
        "cliente",
        "producto",
        "cantidad",
        "precio",
        "vendedor",
        "sucursal"
    ]

    for campo in campos_obligatorios:
        if not registro.get(campo):
            errores.append(f"{campo}_faltante")

    if registro.get("cantidad", 0) <= 0:
        errores.append("cantidad_invalida")

    if registro.get("precio", 0) <= 0:
        errores.append("precio_invalido")

    return errores

15. Control de duplicados

Una ingesta puede traer registros repetidos.

Ejemplo:

def generar_hash_registro(registro):
    clave = f"{registro.get('fecha')}-{registro.get('cliente')}-{registro.get('producto')}-{registro.get('cantidad')}-{registro.get('precio')}"
    return hash(clave)

Uso:

Si el hash ya existe:
marcar como posible duplicado.

Campos frecuentes para detectar duplicados:

fecha
número de comprobante
cliente
producto
importe
sucursal
origen

16. Ingesta por versión FARO

FARO Lite

Carga Excel / CSV.
Google Sheets.
Importación manual.
RAW básico.
Validación mínima.
KPIs iniciales.

Ideal para piloto.

FARO Pro

Carga programada.
Conectores simples.
APIs básicas.
Validación avanzada.
Staging.
Normalización.
Tablas maestras.

Ideal para empresas medianas.

FARO Enterprise

Conectores ERP.
Bancos.
CRM.
POS.
Stock.
Compras.
RRHH.
Pipelines programados.
Auditoría avanzada.

Ideal para multiárea / multisucursal.

FARO Neural

APIs múltiples.
Eventos en tiempo real.
Históricos amplios.
Fuentes externas.
Benchmarks.
Datos no estructurados.
Aprendizaje.
Recalibración.

Requisito: datos confiables e histórico suficiente.

17. Herramientas posibles

18. Seguridad y permisos de ingesta

FARO debe definir permisos desde el inicio.

Regla básica:

Quien carga datos no necesariamente debe poder corregir reglas o aprobar resultados.

Separar roles evita desastres.

19. Riesgos principales de ingesta

20. Ejemplo completo: ingesta de ventas desde Excel

Archivo recibido

ventas_mayo.xlsx

Campos:

fecha
cliente
producto
cantidad
precio
descuento
vendedor
sucursal

Proceso FARO

1. Usuario carga archivo.
2. FARO registra metadata.
3. FARO guarda archivo RAW.
4. FARO valida campos obligatorios.
5. FARO detecta productos no normalizados.
6. FARO pasa datos a staging.
7. FARO normaliza productos y clientes.
8. FARO integra ventas al modelo ejecutivo.
9. FARO calcula ventas netas y descuento promedio.
10. FARO marca margen como incompleto si falta costo.

Resultado

Ventas disponibles.
Descuentos disponibles.
Vendedor disponible.
Sucursal disponible.
Margen parcialmente disponible.
Tensión crecimiento no rentable detectable con confianza media.

21. Ejemplo completo: ingesta de bancos

Fuente

Banco / extracto CSV / API bancaria

Campos:

fecha
concepto
monto
tipo_movimiento
cuenta
referencia

Proceso FARO

1. Importar movimientos.
2. Guardar RAW.
3. Clasificar cobros y pagos.
4. Conciliar contra clientes/proveedores.
5. Detectar movimientos sin identificar.
6. Alimentar caja, cobranzas y pagos.

KPIs habilitados

Flujo de caja operativo.
Cobros diarios.
Pagos diarios.
Cuentas por cobrar conciliadas.
Mora.

Riesgo

Si no se concilia banco contra ERP, FARO puede ver caja pero no saber qué cliente pagó.

22. Ejemplo completo: ingesta de stock

Fuente

ERP / sistema de depósito / Excel de inventario

Campos:

producto
codigo
stock_actual
stock_minimo
ubicacion
ultimo_movimiento
proveedor
plazo_reposicion

Proceso FARO

1. Importar stock actual.
2. Validar productos.
3. Cruzar con maestro de productos.
4. Calcular días de cobertura.
5. Comparar con stock mínimo.
6. Detectar stock crítico.
7. Detectar stock inmovilizado.

Fórmula

Días de cobertura = stock actual / venta promedio diaria

def dias_cobertura(stock_actual, venta_promedio_diaria):
    if venta_promedio_diaria == 0:
        return None
    return stock_actual / venta_promedio_diaria

23. Ejemplo completo: ingesta de decisiones

Fuente:

Reuniones de dirección
Actas
Formulario interno
Tareas

Campos mínimos:

decisión
responsable
área
fecha
vencimiento
estado
KPI relacionado
tensión relacionada

Proceso:

1. Registrar decisión.
2. Asignar responsable.
3. Definir vencimiento.
4. Crear acción.
5. Medir cumplimiento.
6. Conectar con FARO Score.

Sin esta ingesta, FARO puede detectar problemas, pero no medir ejecución.

24. Relación con KPIs y tensiones

25. Output final del Anexo 8

Al finalizar este anexo, FARO debe producir:

1. Inventario de fuentes de datos.
2. Mapa de fuentes por área.
3. Priorización de fuentes a conectar.
4. Método de ingesta por fuente.
5. Frecuencia de actualización.
6. Responsable técnico y responsable de negocio por fuente.
7. Campos principales por fuente.
8. Metadata obligatoria por ingesta.
9. Estados de ingesta.
10. Reglas mínimas de validación.
11. Riesgos por fuente.
12. KPIs habilitados por fuente.
13. Tensiones habilitadas por fuente.
14. Fuentes para fase inicial.
15. Fuentes para fases posteriores.
16. Recomendación técnica de conectores.
17. Roadmap de integración.

26. Conexión con otros anexos

El Anexo 8 define cómo entra la información a FARO Connect. Identifica fuentes, métodos de ingesta, frecuencias, responsables, metadata, validaciones, riesgos y qué KPIs o tensiones habilita cada fuente. Sin una ingesta ordenada, FARO no puede construir dirección confiable.