El CRM genera documentos que hoy viven sueltos en su MinIO: sin nada que los
agrupe y sin catalogo validado en backend. EFC es el sistema de expedientes de
la casa y debe ser la fuente unica, pero el CRM no tiene ni un dato de pedimento
-verificado: ningun campo de aduana, patente, numero ni anio en crm/ ni en ops/-
y en EFC el expediente ES el pedimento. Esta fase pone del lado del CRM lo que
falta para poder hablar de un expediente antes de que exista data aduanera.
crm.expedientes cuelga de la solicitud de servicio, que es el hilo comercial que
el repo ya tiene de la RFQ a la factura. Nace con folio EXP{YYYY}-{MM}-{NNN} en
la misma transaccion del alta: un flush y no un commit, porque si el alta fallara
despues quedaria un folio quemado colgando de una solicitud inexistente.
El folio se reserva con un unico INSERT ... ON CONFLICT DO UPDATE ... RETURNING
sobre crm.expediente_folio_counters. Un SELECT max(sequence)+1 es justo la
carrera que hay que evitar: dos altas simultaneas leerian el mismo maximo y
entregarian el mismo folio a dos expedientes distintos. El asignador no
commitea, igual que el de folios de Anexo22, para que un rollback posterior
pueda soltar el folio; deja hueco, que es preferible a un duplicado. Los dos
UNIQUE de la tabla son la red por si el contador se corrompe: revienta ruidoso
en vez de mezclar dos hilos documentales.
efc_storage_token se fija al nacer y es inmutable: es la carpeta de MinIO en
EFC. Lleva el company_id dentro porque el puente con EFC es tenant -> organizacion
1:1 pero un tenant tiene N companies, asi que sin el, dos companies generando
EXP2026-08-001 chocarian en el unique_together de EFC y a una le devolverian el
provisional de la otra.
EfcDocumentRefMixin va en las dos tablas de documentos -crm.documents y
ops.shipment_documents- porque las dos alimentan el mismo expediente; el handle
autoritativo es efc_document_ref, que el CRM construye, y efc_document_id es
solo cache de la resolucion. El ref es texto y no entero porque las dos tablas
tienen secuencias independientes: crm.documents.id = 5 y
ops.shipment_documents.id = 5 coexisten.
La migracion se GENERA y se deja SIN aplicar.
Verificacion: pytest tests/ EXIT=0, 90 passed 1 skipped (baseline 70 passed).
Los tests nuevos se vieron en rojo a proposito antes de darlos por buenos:
quitando el enganche del expediente reventaron nombrando el expediente ausente,
quitando el UNIQUE del folio el test dijo DID NOT RAISE IntegrityError, y
dejando el contador sin incrementar los tres consecutivos salieron 001/001/001.
Ticket: T2026-08-046 (fase 5 de 7)
CRM — Aduanasoft
Sistema CRM construido sobre la plantilla Workspace de Aduanasoft (SvelteKit 5 + FastAPI + PostgreSQL, multi-tenant con Keycloak/Hub). Gestiona cuentas, contactos, prospectos, oportunidades (pipeline Kanban) y actividades comerciales.
Base:
plantillas-proyectos. Este repo conserva el core de la plantilla (auth, tenants, permisos, licencias) y agrega el dominio CRM en backend y frontend.
Stack
| Capa | Tecnología |
|---|---|
| Frontend | SvelteKit 5 (runes) + Tailwind + shadcn-svelte |
| Backend | FastAPI + SQLAlchemy 2.0 + Pydantic v2 |
| Auth | Keycloak (OIDC) vía Workspace Hub |
| Base de datos | PostgreSQL (schema crm) |
| Cache / Queue | Valkey (Redis) + Celery |
| Storage | MinIO (S3-compatible) |
| Contenedores | Docker Compose |
Módulo CRM
Esquema dedicado crm con 7 tablas multi-tenant (tenant_id + company_id, soft delete):
| Entidad | Tabla | Descripción |
|---|---|---|
| Cuentas | crm.accounts |
Empresas cliente/prospecto (importador, IMMEX, agencia aduanal, transportista). Incluye RFC y patente aduanal. |
| Contactos | crm.contacts |
Personas asociadas a una cuenta. |
| Prospectos | crm.leads |
Leads sin calificar; se convierten en cuenta + contacto + oportunidad. |
| Embudos | crm.pipelines |
Embudos de venta por compañía. |
| Etapas | crm.pipeline_stages |
Columnas del Kanban (con probabilidad y etapas terminales ganada/perdida). |
| Oportunidades | crm.opportunities |
Negocios que avanzan por el embudo. |
| Actividades | crm.activities |
Llamadas, reuniones, tareas, correos y notas. |
Endpoints (prefijo /v1/crm)
Todos reciben company_id como query param y validan permisos vía Keycloak/PermissionService.
GET|POST /accounts,GET|PATCH|DELETE /accounts/{id}GET|POST /contacts,GET|PATCH|DELETE /contacts/{id}GET|POST /leads,GET|PATCH|DELETE /leads/{id},POST /leads/{id}/convertGET|POST /pipelines,PATCH|DELETE /pipelines/{id}GET|POST /stages,PATCH|DELETE /stages/{id}GET|POST /opportunities,GET|PATCH|DELETE /opportunities/{id},PATCH /opportunities/{id}/moveGET|POST /activities,GET|PATCH|DELETE /activities/{id},PATCH /activities/{id}/completeGET /metrics— KPIs y embudo por etapa para el dashboard
Permisos
Se registran en el PermissionRegistry al arrancar (25 permisos: crm.access +
crm.{account,contact,lead,opportunity,pipeline,activity}.{view,create,edit,delete}).
Para persistirlos en BD: POST /v1/core/permissions/sync (o el CLI de sincronización).
Inicio rápido (dev)
cp .env.example .env # ajustar CORE_DB_NAME, Keycloak, etc.
./scripts/auth-mode.sh local # login local sin workspace
docker compose up -d
Abre http://localhost:5173 → CRM en el sidebar.
Migraciones
cd backend
alembic upgrade head # crea el schema crm y sus tablas (revisión f1a2b3c4d5e6)
alembic downgrade -1 # revierte el CRM (down() probado)
Pruebas
Backend (servicios CRM):
cd backend
pytest tests/ -q # 24 pruebas de servicios (SQLite en memoria)
En CI/PostgreSQL, define TEST_DATABASE_URL para ejercitar el esquema real y las
políticas RLS (ver docs/ARCHITECTURE.md).
Estructura del CRM
backend/api/v1/modules/crm/
├── router.py # agrega submódulos bajo /crm (y registra permisos)
├── permissions.py # alta de permisos CRM en el registry
├── accounts/ contacts/ leads/ pipelines/ opportunities/ activities/ metrics/
│ └── models.py · dto.py · service.py · routes.py
backend/alembic/versions/f1a2b3c4d5e6_crm_schema.py
frontend/src/
├── lib/api/crm/ # clientes API tipados por entidad
├── lib/components/crm/ # helpers de formato/etiquetas
└── routes/dashboard/crm/
├── +page.svelte # panel (KPIs + embudo)
├── cuentas/ contactos/ prospectos/ actividades/ # CRUD
└── oportunidades/ # Kanban con drag & drop
Convenciones
- Commits: Conventional Commits (
feat:,fix:,refactor:,chore:) - Ramas:
feature/AS-###-desc,fix/AS-###-desc - Código: nombres en inglés, comentarios de negocio en español
- Backend: Pydantic v2, routers por dominio, filtros multi-tenant explícitos
- Frontend: runes (
$state,$derived,$effect,$props), Tailwind utility-first