"""La llave de almacenamiento del expediente en EFC.

Vive en el carril y no en el módulo del expediente a propósito: el expediente (``crm.cases``) es
del CRM y no sabe nada de EFC; esto es exclusivamente cómo EFC nombra su carpeta.

El generador de folios NO está aquí. Es ``crm/common/folios.py::next_folio``, que ya reserva el
consecutivo mensual por ``(tenant, company, entidad, periodo)`` con bloqueo de fila. El carril lo
consume, no lo reimplementa.
"""

from __future__ import annotations

# Longitud de ``Pedimento.pedimento_app`` en EFC (api/customs/models.py). El token se guarda ahí.
PEDIMENTO_APP_MAX = 25


def storage_token(company_id: int, folio: str) -> str:
    """``CRM-{company_id}-{folio}`` — la llave del pedimento provisional en EFC.

    Empieza con letras, así que es imposible que colisione con la llave de un pedimento real, que
    es ``^\\d{2}-\\d{2}-\\d{4}-\\d{7}$``. El ``company_id`` va dentro porque el puente con EFC es
    tenant → organización 1:1 pero un tenant tiene N companies: sin él, dos companies del mismo
    tenant generarían el mismo ``EXP2026-08-001`` y chocarían en el ``unique_together`` de EFC.

    PRESUPUESTO DE CARACTERES: ``CRM-`` (4) + company + ``-`` (1) + ``EXP2026-08-001`` (14) = 19 +
    los dígitos del company. En los 25 de ``pedimento_app`` caben hasta **6 dígitos** de company,
    no 7 como decía la primera versión de este docstring: con 7 salen 26 y el insert del lado de
    EFC reventaría. Un consecutivo de 4 dígitos (mes con más de 999 expedientes) gasta uno más.

    Se valida en vez de truncar: un token recortado apuntaría a la carpeta de OTRO expediente y
    los documentos se mezclarían en silencio, que es peor que fallar aquí.
    """
    token = f"CRM-{company_id}-{folio}"
    if len(token) > PEDIMENTO_APP_MAX:
        raise ValueError(
            f"storage_token de {len(token)} caracteres excede los {PEDIMENTO_APP_MAX} de "
            f"pedimento_app en EFC: {token!r}. Revisa el largo del company_id o del consecutivo."
        )
    return token
