Base de datos ArcorGev5Reparto — Modelo de tablas y reglas de lectura

Documento de referencia para desarrollo del ArcorTruck BackOffice Web cuando se conecta a la base operativa del cliente (copia de producción restaurada desde .bak).

Base: ArcorGev5Reparto
Motor: SQL Server
Conexión desde el host (Docker): localhost,14333 · usuario sa (solo entorno demo)

1. Resumen ejecutivo

La base agrupa varios conjuntos de tablas con roles distintos. Para el backoffice (reportes, tableros, mapas y consultas al usuario) debe cumplirse esta regla:

Regla de implementación: todos los endpoints, reportes, tableros y mapas del nuevo backoffice deben leer hechos operativos desde tablas E_, enriquecidos con maestros I_. No consultar D_ salvo diagnóstico, soporte o procesos internos de sincronización.

2. Flujo conceptual de datos

   ERP / América                    Equipos móviles
         │                                  │
         ▼                                  ▼
    ┌─────────┐                    ┌─────────────┐
    │  I_*    │  maestros           │    D_*      │  descarga / staging
    │ import  │◄───────────────────│  (parcial)  │  (puede faltar info)
    └────┬────┘                    └──────┬──────┘
         │                               │
         │         validación /          │
         │         consolidación         ▼
         │                        ┌─────────────┐
         └───────────────────────►│    E_*      │  datos validados
                                  │  (completos)│  ◄── BACKOFFICE LEE AQUÍ
                                  └─────────────┘

• D_*: refleja lo recibido desde la calle; útil para auditoría de sync, reintentos o comparar “lo que llegó” vs “lo validado”.
• E_*: refleja lo que el sistema considera correcto y cerrado para operar reportes y pantallas de gestión.

3. Inventario de tablas D_ y E_

Pares homólogos (misma entidad de negocio, distinto estado de pipeline):

Solo en E_: E_DEVOLUCIONES_REPARTO (devoluciones validadas; no existe homólogo D_DEVOLUCIONES_* en este backup).

Observación: en el mismo backup existen tablas sin prefijo (ACTIVIDADES_REPARTIDOR, COBRANZAS, ENTREGAS_*, etc.) con volúmenes muy cercanos a las E_*. Probablemente son capas históricas o espejo del modelo anterior. Para el nuevo backoffice se estandariza E_* como contrato de lectura; cualquier uso de tablas sin prefijo debe validarse con negocio/EMSER antes de implementar.

4. Maestros I_* (complemento obligatorio)

No son hechos de ruta; se importan desde el ERP y alimentan filtros y etiquetas:

Las uniones con E_* son por claves de negocio (ID_REPARTIDOR, NUMERO_HOJA_REPARTO, ID_CUENTA, ID_VISITA, etc.), no por FKs declaradas en SQL.

5. Claves lógicas entre tablas E_*

Tabla central para tablero y mapa: E_ACTIVIDADES_REPARTIDOR (KPIs por visita, montos, contadores de entrega/cobranza, coordenadas GPS).

6. Mapeo casos de uso → tablas E_* + I_*

No usar D_* en ninguna fila de la tabla anterior.

7. Qué hacer con D_* (alcance permitido)

Ejemplo de consulta de control (solo monitoreo):

-- Visitas en descarga móvil que aún no tienen par validado (ilustrativo)
SELECT COUNT(*) AS SoloEnDescarga
FROM D_ACTIVIDADES_REPARTIDOR d
WHERE NOT EXISTS (
  SELECT 1 FROM E_ACTIVIDADES_REPARTIDOR e
  WHERE e.ID_VISITA = d.ID_VISITA
);

8. Implicaciones para la API .NET

1. Cadena de conexión: Database=ArcorGev5Reparto (no GotruckDemo).
2. No ejecutar migraciones EF del prototipo demo sobre esta base (esquema ajeno).
3. Repositorios / SQL: nombrar explícitamente tablas E_* en consultas o vistas (v_Reporte_* sobre E_*).
4. DTOs del backoffice: alineados a columnas E_* (p. ej. MONTO_COBRADO, GPS_LATITUD en E_ACTIVIDADES_REPARTIDOR).
5. Filtros de fecha/hoja/repartidor: siempre aplicados en capa E_* para evitar mezclar datos incompletos de D_*.

9. Otras tablas (referencia)

10. Documentos relacionados

Convención acordada: E_* = datos validados para backoffice · D_* = descarga móvil (incompleta) · I_* = maestros.