Entidades del Ciclo Comercial

Modulo: CRM / Ventas / Compras Tipo: resource (transversal) Estado: parcialmente implementado Fecha: 2026-03-30

Descripcion

Mapa de entidades que participan en el ciclo comercial y sus relaciones. Estas entidades son reutilizables entre modulos y determinan flujos de facturacion, comisiones y seguimiento.

Aclaración: Nota de Pedido vs. Budget CRM

La Nota de Pedido es un recurso independiente del budget (presupuesto CRM). No existe FK entre nota_pedido y budget. Los ítems de la NP provienen del catálogo de productos de Ventas, no del presupuesto CRM. Son flujos paralelos que coexisten:

budget → prefa: flujo de presupuestos CRM (existente)
nota_pedido → nota_venta → prefa: flujo comercial (nuevo)

Diagrama de relaciones (ERD)

mermaid

erDiagram
    PROVEEDOR["Proveedor (cpdprov)"] {
        int cnro PK
        string nombre
        string concesi "S/N - flag concesionario"
        int ccar FK "cartera proveedor"
    }
    CLIENTE["Cliente (ordcon)"] {
        int cnro PK
        string nombre
        boolean es_concesionario "NUEVO - flag explicito"
        int vendedor FK
        string lista
    }
    CONTACTO["Contacto (contacto)"] {
        int id_contact PK
        string nombre
        string identificacion
        string correo
        int cliente_id FK "nullable"
        int id_tipo_contacto FK
    }
    CRM_RECORD["Registro CRM (crm_records)"] {
        uuid id PK
        int contact_id FK
        int crm_type_id FK
        datetime fecha
        string titulo
    }
    CRM_EXT_COMERCIAL["Ext Comercial (crm_ext_industrial)"] {
        int id PK
        uuid crm_id FK
        int concesi FK "derivacion a concesionaria"
        boolean es_licitacion
        boolean tiene_poliza
    }
    NOTA_PEDIDO["Nota de Pedido"] {
        uuid id PK
        uuid crm_record_id FK
        int cliente_id FK
        string modalidad_venta "A/B/C/D"
    }
    NOTA_VENTA["Nota de Venta"] {
        uuid id PK
        uuid nota_pedido_id FK
        int concesionario_id FK "nullable"
        int vendedor_id FK
    }
    ADQUIRENTE_NP["Adquirente NP (nota_pedido_adquirente)"] {
        uuid id PK
        uuid nota_pedido_id FK
        string nombre
        string cuit
        string domicilio
        string condicion_iva
        decimal importe
    }
    ADQUIRENTE_NV["Adquirente NV (nota_venta_adquirente)"] {
        uuid id PK
        uuid nota_venta_id FK
        string nombre
        string cuit
        string domicilio
        string condicion_iva
        decimal importe
    }
    CLIENTE ||--o{ CONTACTO : "1:N tiene contactos"
    CONTACTO ||--o{ CRM_RECORD : "1:N tiene registros CRM"
    CRM_RECORD ||--o| CRM_EXT_COMERCIAL : "1:1 extension comercial"
    CRM_EXT_COMERCIAL }o--|| PROVEEDOR : "derivacion a concesionaria"
    CRM_RECORD ||--o| NOTA_PEDIDO : "1:1 genera pedido"
    NOTA_PEDIDO ||--o| NOTA_VENTA : "1:1 genera NV"
    NOTA_PEDIDO ||--o| ADQUIRENTE_NP : "1:1 adquirente (nullable)"
    NOTA_VENTA ||--o| ADQUIRENTE_NV : "1:1 adquirente (nullable)"

Adquirente — relación 1:1: Tanto nota_pedido_adquirente como nota_venta_adquirente tienen relación 1:1 con su documento padre (un solo tercero por operación). Si una NV debe facturarse en múltiples CUITs (ej: 50% CUIT X, 50% CUIT Y), se emite una factura por CUIT con el mismo adquirente, y el remito aclara la distribución porcentual — pero sigue siendo UN SOLO tercero registrado. Al confirmar una NP, el adquirente se copia automáticamente de nota_pedido_adquirente a nota_venta_adquirente.

Entidades detalladas

1. Concesionario — dual registration

Un concesionario existe en el sistema como dos entidades separadas:

mermaid

flowchart LR
    subgraph PROVEEDOR["Como Proveedor (cpdprov)"]
        P[cnro: 4402<br/>concesi: S]
    end
    subgraph CLIENTE["Como Cliente (ordcon)"]
        C1[cnro: 3483<br/>es_concesionario: true]
    end
    P -.- C1
    style P fill:#f9f,stroke:#333
    style C1 fill:#bbf,stroke:#333

Aspecto	Como Proveedor	Como Cliente
Tabla	`cpdprov`	`ordcon`
Flag concesionario	`concesi = 'S'` (implementado)	`es_concesionario = true` (implementado 2026-03-31)
Para que se usa	Recibe facturas de comision, pagos	Es el comprador, genera NV, recibe bonificaciones
API	`GET /concesi` (ConcesionarioRoute)	`GET /clientes` filtrado por flag

Nota sobre carteras: La cartera (ordcon.ccar) es un dato configurable por el usuario para clasificacion contable. NO determina si un cliente es concesionario. La marca de concesionario debe ser un flag independiente de la cartera asignada.

Decisión (2026-03-31): Formalizar es_concesionario: boolean en el modelo de Cliente (ordcon), similar al flag concesi = 'S'/'N' que ya existe en Proveedor (cpdprov). Este flag es la única forma confiable de identificar un cliente concesionario, independientemente de su cartera. nota_venta.concesionario_id apunta a un registro ordcon con este flag en true. No se requiere FK formal entre ordcon y cpdprov en esta etapa.

Resuelto (2026-03-31): nota_venta.concesionario_id es FK a ordcon donde es_concesionario = true. Se agrega flag es_concesionario BOOLEAN a ordcon. No se requiere FK formal entre ordcon y cpdprov en esta etapa — la relación queda por convención de datos.

2. Cliente

Campo clave	Descripcion
`cnro`	ID unico (DECIMAL(6) → int)
`vendedor`	Vendedor asignado
`lista`	Lista de precios asignada
`es_concesionario`	NUEVO — flag explicito booleano
`ccar`	Cartera del cliente (configuracion contable del usuario, no determina tipo de cliente)

Importante: La cartera es un dato de configuracion contable que el usuario asigna libremente. No tiene relacion con el flag es_concesionario. Un concesionario puede estar en cualquier cartera segun la politica contable de la empresa.

3. Contacto

Campo clave	Descripcion
`id_contact`	ID unico (auto-increment)
`cliente_id`	FK nullable a `ordcon.cnro`
`codtco`	Tipo de contacto

Relacion con Cliente: N:1 (muchos contactos → un cliente). Un contacto pertenece a un solo cliente. Un cliente puede tener multiples contactos (diferentes interlocutores de la misma empresa).

Relacion con CRM: N:1 (muchos registros CRM → un contacto). Todo registro CRM requiere un contacto.

4. Cadena de resolucion: CRM → Cliente

La cadena completa para resolver un cliente desde un registro CRM es:

mermaid

flowchart LR
    CRM["CRM Record<br/>(crm_records)"]
    CON["Contacto<br/>(contacto)"]
    CLI["Cliente<br/>(ordcon)"]
    CRM -->|contact_id| CON
    CON -->|cliente_id| CLI
    CLI -->|ccar| CAR["Cartera"]

Esta cadena se usa en:

Presupuesto CRM → Prefactura (resolucion del cliente para facturar)
Nota de Pedido (resolucion del concesionario/cliente desde el CRM de origen)
Nota de Venta (hereda el cliente via NP → CRM → Contacto → Cliente)

Flujo de datos: concesionario en el ciclo comercial

mermaid

flowchart TB
    subgraph REGISTRO["1. Registro CRM"]
        CRM[Registro CRM Comercial]
        CRM --> CON[Contacto del concesionario]
        CON --> CLI_C[Cliente: cartera 1-CONCESIONARIOS]
        CRM --> EXT[Ext Comercial: concesi = proveedor_id]
    end

    subgraph PEDIDO["2. Nota de Pedido"]
        NP[Nota de Pedido]
        NP --> CLI_C
        NP --> MOD[Modalidad A/B/C/D]
        NP --> BONIF[Bonificaciones del concesionario]
    end

    subgraph VENTA["3. Nota de Venta"]
        NV[Nota de Venta]
        NV --> CLI_C
        NV --> ADQ[Adquirente: CUIT X<br/>importe total a facturar]
    end

    subgraph FACTURACION["4. Facturacion"]
        FAC1[Factura A → Adquirente 50% CUIT X]
        FAC2[Factura A → Adquirente 50% CUIT X]
        REM[Remito → aclara % por CUIT]
    end

    subgraph COMISION["5. Comision"]
        PROV[Proveedor: concesi = S]
        PROV --> FCOM[Factura de comision<br/>si facturado > costo]
    end

    CRM --> NP
    NP --> NV
    NV --> ADQ
    ADQ --> FAC1
    ADQ --> FAC2
    ADQ --> REM
    NV -.->|diferencia costo vs facturado| PROV

Datos reutilizables entre modulos

Las siguientes entidades son compartidas y reutilizadas a lo largo del ciclo:

Entidad	Modulos que la usan	Datos que aporta
Cliente (ordcon)	CRM, Ventas, CtaCte, Tesoreria	Razon social, CUIT, direccion, vendedor, lista de precios, flag es_concesionario
Contacto	CRM	Interlocutor, telefono, email, vinculo a cliente
Proveedor (cpdprov)	Compras, Comisiones	Razon social, CUIT, flag concesionario
Concesionario (dual)	CRM (como derivacion), Ventas (como cliente), Compras (como proveedor), Comisiones	Bonificaciones, politicas de comision, red comercial

Flag `es_concesionario` en Cliente (implementado 2026-03-31)

Estado anterior

ordcon.CONCESI → campo texto, no vacio = concesionario (contenido no formalizado)

Estado actual

ordcon.es_concesionario → boolean (true/false), flag explicito
ordcon.CONCESI → se mantiene por compatibilidad legacy

Ventajas del flag explicito

Consulta directa sin depender de datos legacy ni de la cartera asignada
Consistente con el patron de proveedores (cpdprov.concesi = 'S'/'N')
La cartera es configuracion contable del usuario, no debe usarse para determinar tipo de cliente
Simplifica la logica de negocio en NV (campo concesionario_id en NV apunta a un cliente con es_concesionario = true)

Proceso relacionado

→ flujo-comercial-process → analisis-requerimientos-nv → comisiones-resource → nota-venta-resource

Joins

Retenciones

Ganancias

Sicore

Catalogos

Comercializacion

Extensiones

Presupuestos

Tercerizacion

Recursos Principales

Relaciones

Ciclo Comercial

Administracion

Comercial

Produccion

Tesoreria

Catalogos Base

Cupon Pago

Facturacion

Gestion Miembros

Grupos Familiares

Soporte Tecnico

Architecture

Backend

Api

Database

Migrations

Middleware

Security

Services

Deployment

Development

Testing

Frontend

Integrations

Payment Gateways

Retenciones

Entidades del Ciclo Comercial ​

Descripcion ​

Aclaración: Nota de Pedido vs. Budget CRM ​

Diagrama de relaciones (ERD) ​

Entidades detalladas ​

1. Concesionario — dual registration ​

2. Cliente ​

3. Contacto ​

4. Cadena de resolucion: CRM → Cliente ​

Flujo de datos: concesionario en el ciclo comercial ​

Datos reutilizables entre modulos ​

Flag es_concesionario en Cliente (implementado 2026-03-31) ​

Estado anterior ​

Estado actual ​

Ventajas del flag explicito ​

Proceso relacionado ​

Entidades del Ciclo Comercial

Descripcion

Aclaración: Nota de Pedido vs. Budget CRM

Diagrama de relaciones (ERD)

Entidades detalladas

1. Concesionario — dual registration

2. Cliente

3. Contacto

4. Cadena de resolucion: CRM → Cliente

Flujo de datos: concesionario en el ciclo comercial

Datos reutilizables entre modulos

Flag `es_concesionario` en Cliente (implementado 2026-03-31)

Estado anterior

Estado actual

Ventajas del flag explicito

Proceso relacionado