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)
70 lines
3.3 KiB
Python
70 lines
3.3 KiB
Python
from datetime import datetime
|
|
|
|
from sqlalchemy import DateTime, ForeignKey, Integer, String, Text, text
|
|
from sqlalchemy.orm import Mapped, mapped_column
|
|
from sqlalchemy.sql import func
|
|
|
|
|
|
class BaseTimestampMixin:
|
|
"""Mixin for basic timestamp fields (no soft delete)"""
|
|
|
|
created_at: Mapped[datetime] = mapped_column(
|
|
DateTime, nullable=False, server_default=func.now()
|
|
)
|
|
updated_at: Mapped[datetime] = mapped_column(
|
|
DateTime, nullable=False, server_default=func.now(), onupdate=func.now()
|
|
)
|
|
|
|
|
|
class TimestampMixin(BaseTimestampMixin):
|
|
"""Mixin for common timestamp fields including soft delete"""
|
|
|
|
deleted_at: Mapped[datetime | None] = mapped_column(DateTime, nullable=True)
|
|
|
|
|
|
class TenantScopedMixin:
|
|
"""Mixin para entidades multi-tenant.
|
|
|
|
company_id no tiene FK declarada aquí — agrégala en cada modelo
|
|
apuntando a la tabla de compañías de tu proyecto.
|
|
"""
|
|
|
|
tenant_id: Mapped[int] = mapped_column(Integer, ForeignKey("core.tenants.id"), nullable=False, index=True)
|
|
company_id: Mapped[int] = mapped_column(Integer, nullable=False, index=True)
|
|
|
|
|
|
class EfcDocumentRefMixin:
|
|
"""Columnas del espejo de un documento en EFC. Se aplica a ``crm.documents`` y a
|
|
``ops.shipment_documents``.
|
|
|
|
``efc_document_ref`` es el handle AUTORITATIVO —el CRM lo construye y EFC lo guarda—;
|
|
``efc_document_id`` es solo un CACHE de la resolución, recuperable por el endpoint de lista si
|
|
se pierde. Es el mismo principio que aplica el gateway de Anexo22: el sistema de origen conserva
|
|
el registro de SU dato, y con eso pide el archivo de vuelta, en lugar de guardar identificadores
|
|
ajenos en columnas propias.
|
|
|
|
``efc_sync_state`` es el estado del ESPEJO (lo que pinta la UI: badge, botón reintentar). La
|
|
cola de trabajo vive aparte, en ``crm.efc_file_outbox``. No son redundantes: el outbox es
|
|
indexable por su propio ciclo de vida y sobrevive a un borrado cuya fila ya no está.
|
|
|
|
Es un mixin y no diez columnas copiadas en dos modelos porque las dos tablas tienen que
|
|
describir el mismo espejo: si divergen, la UI pinta un badge distinto según de dónde venga el
|
|
documento y nadie entiende por qué.
|
|
"""
|
|
|
|
expediente_id: Mapped[int | None] = mapped_column(Integer, nullable=True, index=True)
|
|
# {TABLA}-{company_id}-{row_id}, p. ej. SHPDOC-1-4471. Texto y no un entero porque el CRM tiene
|
|
# dos tablas de documentos con secuencias independientes: crm.documents.id = 5 y
|
|
# ops.shipment_documents.id = 5 coexisten, así que un entero solo sería ambiguo entre ellas.
|
|
efc_document_ref: Mapped[str | None] = mapped_column(String(64), nullable=True, index=True)
|
|
efc_document_id: Mapped[str | None] = mapped_column(String(36), nullable=True)
|
|
# PENDING | SYNCED | FAILED
|
|
efc_sync_state: Mapped[str | None] = mapped_column(
|
|
String(20), nullable=True, server_default=text("'PENDING'")
|
|
)
|
|
efc_synced_at: Mapped[datetime | None] = mapped_column(DateTime, nullable=True)
|
|
efc_error_code: Mapped[str | None] = mapped_column(String(60), nullable=True)
|
|
efc_error_detail: Mapped[str | None] = mapped_column(Text, nullable=True)
|
|
efc_attempts: Mapped[int | None] = mapped_column(Integer, nullable=True, server_default=text("0"))
|
|
content_sha256: Mapped[str | None] = mapped_column(String(64), nullable=True)
|