El Problema: El laberinto de las pólizas dinámicas La necesidad era clara: si se agrega un nuevo valor o cambia un factor de cálculo, el sistema debe ser capaz de procesarlo sin que yo tenga que abrir el IDE, modificar una función, probar y desplegar de nuevo. Buscábamos eliminar la reescritura constante y apostar por funciones globales y alias dinámicos.

En lugar de tener una función calcular_igi_por_po(), creamos un motor que entiende qué es @IGIPORPO y cómo debe comportarse en el contexto de un pedimento específico.

La Solución: Un motor de evaluación en la trinchera El núcleo de esta arquitectura es un evaluador que procesa macros y fórmulas complejas. Aquí no estamos hablando de simples sumas; hablamos de lógica que debe conciliar datos provenientes de XMLs, PDFs e imágenes procesadas por IA, donde el margen de error es crítico.

python

Un vistazo al motor de evaluación (evaluator.py)

async def evaluar_expresion(expr, contexto): raw = expr.strip() up = raw.upper().replace(" ", "")

# Aliases base que resuelven el contexto contable
if up_no_us == "@PEDIMENTO":
    return contexto["pedimento"]
if up_no_us == "@ANTICIPO":
    return contexto["anticipo"]

# Lógica compleja de IVA y Retenciones inyectada dinámicamente
if up_no_us in ("@RETENCIONES", "@RETENCIONES()"):
    from creacion_polizas_desde_config.iva import calcular_retenciones_totales
    # ... lógica de cálculo y redondeo ...

Este enfoque permite que la lógica pesada resida en la configuración, no en el binario. Una fórmula de póliza puede verse tan compleja como esta:

json { "DetailComment": "FREIGHT IN", "Amount": "@RESTA( @RESTA( @RESTA( @MULT(@DIV(@PESO_PO,@SUMA_PESOS), @RESTA(@TOTAL_CG, @IVA, @TOTALFREIGHT())), @MULT(@DIV(@PESO_PO,@SUMA_PESOS), @IGI_API()) ), @MULT(@DIV(@PESO_PO,@SUMA_PESOS), @IVA_API()) ), @NEGATIVE(@RETENCIONES()) )" } La Frustración: Donde la abstracción se encuentra con la realidad Mantener una arquitectura así no es gratis. El mayor reto no es el performance, sino las validaciones. Nos enfrentamos a múltiples tipos de pólizas donde la IA a veces clasifica mal las fracciones arancelarias, el IGI se asigna de manera incorrecta o aparecen nuevas claves de desglose que no estaban contempladas.

El debugging se vuelve un arte. Tienes que entender por qué una macro devolvió un valor inesperado en un escenario de retenciones que solo ocurre en el 1% de los casos.

Opinión: Abstracción vs. Escalabilidad No se trata de abusar de las abstracciones por ego técnico. Se trata de reducir operaciones y facilitar la vida. En Prometeo, el usuario no tiene que leer archivos PDF o XML manualmente; la IA hace el trabajo sucio de conciliación y el evaluador une los importes con las claves de concepto. Es automatización real aplicada a problemas aburridos pero críticos.

Un consejo para el que herede este código Si vas a trabajar en un sistema como este, mi advertencia número uno es: entiende las reglas de negocio antes de tocar una sola línea de código.

Entiende el flujo desde la creación del anticipo hasta la conciliación y el cierre. La lógica más pesada no está en las APIs; está en entender las múltiples condiciones que rigen el algoritmo de generación de pólizas. Aunque parezcan simples sumas y restas, la verdadera ingeniería está en la fórmula que garantiza que el saldo cuadre al centavo.