marcos
39347f9c97
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)
118 lines
6.6 KiB
Python
118 lines
6.6 KiB
Python
from datetime import date
|
|
|
|
from sqlalchemy import Date, ForeignKey, Integer, String, Text, UniqueConstraint, text
|
|
from sqlalchemy.orm import Mapped, mapped_column
|
|
|
|
from api.v1.common.base_models import TenantScopedMixin, TimestampMixin
|
|
from core.database import Base
|
|
|
|
|
|
class Expediente(Base, TenantScopedMixin, TimestampMixin):
|
|
"""Expediente del CRM: el hilo documental de una operación, de la RFQ a la factura.
|
|
|
|
El ancla es la solicitud de servicio (``crm.service_requests``): un expediente por hilo
|
|
comercial, siguiendo la cadena que el CRM ya tiene. En EFC cada expediente se refleja como un
|
|
*pedimento provisional* cuyo ``pedimento_app`` es el ``efc_storage_token``, y cuando llega la
|
|
data aduanera real ese provisional se completa sin mover un solo archivo.
|
|
|
|
El folio va DESCOMPUESTO en ``period_year`` / ``period_month`` / ``sequence`` además de
|
|
guardarse armado en ``folio``: así el consecutivo es un constraint real de la base y no un
|
|
parse de string. ``uq_crm_expedientes_periodo_seq`` es la red de seguridad — si el contador se
|
|
corrompe, un folio duplicado falla ruidosamente en vez de mezclar dos expedientes.
|
|
|
|
Los campos ``efc_*`` son un ESPEJO de lo que hay en EFC, nunca el handle. El handle que el CRM
|
|
usa para hablar de este expediente es su ``folio`` y su ``id``: ``efc_pedimento_id`` es un cache
|
|
de la resolución y ``pedimento_app`` del lado de EFC es mutable —se reescribe al completar—, así
|
|
que apoyarse en él rompería en cuanto la data real llegue.
|
|
|
|
``efc_storage_token`` es INMUTABLE una vez asignado: es la carpeta de MinIO donde EFC guarda los
|
|
objetos de este expediente. Que no cambie nunca es lo que hace que completar el pedimento no
|
|
obligue a mover archivos.
|
|
"""
|
|
|
|
__tablename__ = "expedientes"
|
|
__table_args__ = (
|
|
UniqueConstraint("tenant_id", "company_id", "folio", name="uq_crm_expedientes_folio"),
|
|
UniqueConstraint(
|
|
"tenant_id",
|
|
"company_id",
|
|
"period_year",
|
|
"period_month",
|
|
"sequence",
|
|
name="uq_crm_expedientes_periodo_seq",
|
|
),
|
|
{"schema": "crm"},
|
|
)
|
|
|
|
id: Mapped[int] = mapped_column(Integer, primary_key=True, index=True)
|
|
|
|
# ── Folio ──────────────────────────────────────────────────────────────────────────────
|
|
folio: Mapped[str] = mapped_column(String(20), nullable=False, index=True) # EXP2026-08-001
|
|
period_year: Mapped[int] = mapped_column(Integer, nullable=False)
|
|
period_month: Mapped[int] = mapped_column(Integer, nullable=False)
|
|
sequence: Mapped[int] = mapped_column(Integer, nullable=False)
|
|
|
|
# ── Anclas comerciales ─────────────────────────────────────────────────────────────────
|
|
service_request_id: Mapped[int | None] = mapped_column(
|
|
Integer, ForeignKey("crm.service_requests.id"), nullable=True, index=True
|
|
)
|
|
account_id: Mapped[int | None] = mapped_column(
|
|
Integer, ForeignKey("crm.accounts.id"), nullable=True, index=True
|
|
)
|
|
|
|
# abierto | completado | cerrado
|
|
status: Mapped[str] = mapped_column(
|
|
String(20), nullable=False, server_default=text("'abierto'"), index=True
|
|
)
|
|
|
|
# ── Espejo de EFC ──────────────────────────────────────────────────────────────────────
|
|
efc_organizacion_id: Mapped[str | None] = mapped_column(String(36), nullable=True)
|
|
efc_pedimento_id: Mapped[str | None] = mapped_column(String(36), nullable=True)
|
|
efc_storage_token: Mapped[str | None] = mapped_column(String(25), nullable=True)
|
|
# PENDING | LINKED | FAILED
|
|
efc_link_state: Mapped[str] = mapped_column(
|
|
String(20), nullable=False, server_default=text("'PENDING'")
|
|
)
|
|
# El diagnóstico se guarda en la fila para que se vea en la ficha, sin obligar a ir a los logs.
|
|
efc_error_code: Mapped[str | None] = mapped_column(String(60), nullable=True)
|
|
efc_error_detail: Mapped[str | None] = mapped_column(Text, nullable=True)
|
|
|
|
# ── Data aduanera real: se llena al completar, no al crear ─────────────────────────────
|
|
# Longitudes tomadas de api/customs/models.py::Pedimento en EFC, que es el destino de estos
|
|
# datos: patente 20, aduana 10, regimen 10, clave_pedimento 10, RFC del agente 100.
|
|
patente: Mapped[str | None] = mapped_column(String(20), nullable=True)
|
|
aduana: Mapped[str | None] = mapped_column(String(10), nullable=True)
|
|
numero_pedimento: Mapped[str | None] = mapped_column(String(20), nullable=True)
|
|
anio: Mapped[int | None] = mapped_column(Integer, nullable=True)
|
|
clave_pedimento: Mapped[str | None] = mapped_column(String(10), nullable=True)
|
|
regimen: Mapped[str | None] = mapped_column(String(10), nullable=True)
|
|
fecha_pago: Mapped[date | None] = mapped_column(Date, nullable=True)
|
|
rfc_importador: Mapped[str | None] = mapped_column(String(20), nullable=True)
|
|
rfc_agente_aduanal: Mapped[str | None] = mapped_column(String(100), nullable=True)
|
|
|
|
created_by: Mapped[str | None] = mapped_column(String(64), nullable=True)
|
|
updated_by: Mapped[str | None] = mapped_column(String(64), nullable=True)
|
|
|
|
|
|
class ExpedienteFolioCounter(Base):
|
|
"""Contador de folios por ``(tenant, company, mes)``.
|
|
|
|
Tabla propia y no un ``max(sequence) + 1`` sobre ``crm.expedientes``: ese SELECT es exactamente
|
|
la carrera que hay que evitar. Aquí el consecutivo se reserva con un solo
|
|
``INSERT ... ON CONFLICT DO UPDATE ... RETURNING`` (ver ``folio.py``), que serializa sobre esta
|
|
fila y devuelve el valor ya incrementado.
|
|
|
|
No lleva los mixins de tenant ni de timestamps a propósito: ``tenant_id`` y ``company_id`` son
|
|
parte de la PK compuesta, y una fila de contador no tiene ciclo de vida propio que auditar.
|
|
"""
|
|
|
|
__tablename__ = "expediente_folio_counters"
|
|
__table_args__ = {"schema": "crm"}
|
|
|
|
tenant_id: Mapped[int] = mapped_column(
|
|
Integer, ForeignKey("core.tenants.id"), primary_key=True, nullable=False
|
|
)
|
|
company_id: Mapped[int] = mapped_column(Integer, primary_key=True, nullable=False)
|
|
period: Mapped[str] = mapped_column(String(7), primary_key=True, nullable=False) # "2026-08"
|
|
last_seq: Mapped[int] = mapped_column(Integer, nullable=False, server_default=text("0"))
|