ALEPH CRM — Decision Log

Propósito

Documentar las decisiones de diseño del flujo Gemelo → ALEPH → CRM.

D-001 — Orden jerárquico

El flujo sigue:

EMPRESA → PERSONA → PERSONA_PROYECTO

Razón: evitar registros huérfanos y mantener integridad en ALEPH.

D-002 — Dry-run obligatorio

Toda escritura pasa por:

preview → dry-run → ejecución

Razón: minimizar errores en base productiva y permitir auditoría.

D-003 — Resolución de empresa

Se resuelve por:

  1. NIT

  2. nombre normalizado

Estados:

  • MATCHED

  • AMBIGUOUS

  • NOT_FOUND

D-004 — Creación de empresa condicionada

Solo se permite crear empresa si existe NIT.

Razón: evitar contaminar maestros con datos incompletos.

D-005 — Contacto mínimo

Para CRM operativo se requiere:

  • full_name

  • email o phone

D-006 — Regla de nombres

  • 1 palabra → nombre

  • 2 palabras → nombre + apellido

  • 3+ palabras → nombre = todas menos última

Siempre:

nombreC = full_name

D-007 — Defaults de EMPRESAS

  • id_tipo = “NA”

  • id_estado = “OK”

  • persona_natural = 0

Razón: usar valores válidos mínimos mientras no se modele completamente.

D-008 — Idempotencia CRM

Antes de escribir:

PERSONAS:

  • buscar por email

  • o por (nombre + NIT)

PERSONA_PROYECTO:

  • buscar por (id_persona + id_proyecto)

Si ambos existen:

→ CRM_ALREADY_SYNCED

D-009 — Separación lectura/escritura DB

  • run_query → SELECT

  • run_execute → INSERT/UPDATE

Razón: evitar errores por uso incorrecto de funciones.

D-010 — Proyecto interno obligatorio

Para CRM operativo se requiere:

internal_commercial_project_id

Razón: PERSONA_PROYECTO depende de ese identificador.

D-011 — Vendor registration no bloqueante

Inicialmente se consideró como prerequisito.

Se corrigió a:

  • NO bloquea contacto ni actividad inicial

  • SÍ afecta madurez comercial

Razón: en la práctica comercial se puede iniciar contacto antes del registro.