Este documento detalla el funcionamiento y la arquitectura del sistema de extensión  TryDockCmd v1.1.30 , diseñado para la gestión automatizada de paquetes del sistema, dependencias de Python y módulos externos (comunitarios o de partners) dentro de entornos Docker para Tryton.

Los puntos clave de esta versión incluyen:

  • Motor Híbrido:  Separación clara entre la interfaz de usuario (install_modules.bat) y la lógica de inyección (install_external.bat).
  • Inteligencia de Localización:  El sistema detecta el «ADN contable» mediante la validación de prefijos para evitar conflictos críticos entre las bases contables de NaN-tic y las de la COMUNIDAD.
  • Cumplimiento Legal:  Automatización de flujos de negocio críticos para la normativa española, incluyendo  Facturae  (Ley Crea y Crece),  Verifactu  (Ley Antifraude) y el  SII .
  • Técnicas de Inyección Avanzadas:  Implementación de «Pure Injection» para resolver incompatibilidades de instaladores heredados y garantizar la integridad de archivos XML y locales.
  • Trazabilidad Total:  Registro exhaustivo de cada instalación mediante hashes de Git en registros de auditoría para soporte técnico y seguridad.

1. Filosofía y Estructura del Sistema

El gestor TryDockCmd opera bajo un modelo de dos capas que garantiza tanto la facilidad de uso como una resolución de dependencias robusta.

1.1. Componentes del Sistema

Componente,Archivo,Función

Interfaz,install_modules.bat,Menú interactivo para la selección de paquetes y módulos.

Motor de Inyección,install_external.bat,»Lógica inteligente que resuelve dependencias, busca repositorios y realiza la inyección de código.»

1.2. Preparación Obligatoria (Opción 8 y 10 del Menú)

Antes de cualquier intervención, el sistema establece dos requisitos críticos:

  1. Backup (Opción 1):  Es mandatorio realizar una copia de seguridad, ya que la inyección de módulos modifica la estructura de archivos del contenedor y el esquema de la base de datos.
  2. Herramientas de Control de Versiones (Opción 2):  Instalación de git y hg (Mercurial) dentro del contenedor para permitir la descarga de código en tiempo real desde repositorios como GitHub (NANTIC) o Heptapod (COMMUNITY).

2. Gestión de Dependencias y Flujos de Negocio

2.1. Dependencias de Python Cruciales

El sistema automatiza la instalación de librerías necesarias para la comunicación con la AEAT y la generación de documentos:

  • SignXML:  Requisito absoluto para los módulos NANTIC y COMMUNITY; permite la firma XAdES de Facturae y Verifactu.
  • XMLSIG / pyOpenSSL / Jinja2:  Específicos para flujos de NANTIC, facilitando comunicaciones avanzadas con la agencia tributaria y generación dinámica de documentos.
2.2. Flujos de Negocio Automatizados

El motor detecta automáticamente la versión de Tryton (7.0 hasta 8.0) basándose en el archivo .env, recomendando la versión 7.0 por su estabilidad LTS. Los módulos principales incluyen:

  • Facturae:  Facturación electrónica española.
  • Verifactu:  Adaptación a la nueva normativa antifraude (fecha crítica: 1 de enero de 2027).
  • SII:  Suministro Inmediato de Información.

3. Lógica del Motor de Inyección (install_external)

El motor sigue un proceso riguroso para asegurar que no existan conflictos de software ni de modelos contables.

3.1. Validación de Ancla Contable (PREFIX)

Para evitar la mezcla incompatible de modelos contables en España, el script analiza el archivo setup.py del módulo account_es ya instalado:

  • Si detecta  PREFIX.*’nantic’  :  El sistema identifica la base como de NaN-tic y prioriza su repositorio oficial en GitHub.
  • Si NO detecta el prefijo:  Asume una instalación de la COMUNIDAD y bloquea automáticamente a NANTIC como proveedor para proteger la integridad de las cuentas contables.
3.2. Estrategia de Búsqueda y Resolución de Versiones

El sistema sigue una secuencia de búsqueda jerárquica:

    • Verificación de Existencia:  Comprueba si el módulo ya está activado en la base de datos o si es importable como paquete de Python. Si existe, se marca como NATIVE y se omite la descarga.
  • Jerarquía de Proveedores:
  • COMMUNITY (Heptapod):  Intenta clonar la rama que coincide con la versión LTS. Si falla, busca la rama por defecto o el tag más alto compatible. No permite versiones superiores a la de Tryton instalada.
  • TRYDOCKCMD (Local):  Busca en la ruta local del host (modules/es/{version}/).
  • NANTIC (GitHub):  Utiliza un mapeo interno para traducir nombres de módulos a nombres de repositorios y paquetes Pip (ej. account_es_verifactu se traduce a trytond-aeat_verifactu).
3.3. Técnica «Pure Injection»

Para módulos con instaladores antiguos o problemáticos (ej. account_common), el sistema emplea la «Inyección Pura»:

  • Clona el repositorio en una carpeta temporal del host.
  • Inyecta los archivos directamente en el volumen de Tryton.
  • Ejecuta setup.py dentro del contenedor para registrar los  entry-points , asegurando la correcta copia de archivos XML y locales.

4. Proceso de Activación y Estabilización

Una vez inyectados los archivos, el sistema ejecuta una serie de comandos trytond-admin para integrar los cambios:

  1. Activación Inicial:  Ejecución con el flag -u {modulo} –activate-dependencies para activar el módulo y su árbol de dependencias.
  2. Actualización de Lista:  Comando –update-modules-list para que Tryton reconozca los nuevos archivos en el sistema de ficheros (actualiza la tabla ir_module).
  3. Actualización Global y Traducciones:  Uso del parámetro –all para reconstruir la base de datos y -l {idioma} para refrescar menús e interfaces con las traducciones correctas.
  4. Reinicio de Servicios:  Parada y arranque de los contenedores trytond y trytond-cron para limpiar cachés y estabilizar el sistema.

5. Auditoría, Registro y Diagnóstico

5.1. Trazabilidad de Instalación

El sistema genera un registro en log/modules_git_audit.txt que incluye:

  • Nombre del módulo.
  • Proveedor (COMMUNITY, NANTIC,  TRYDOCKCMD).
  • Rama o Tag utilizado.
  • Commit Hash (ID):  Garantiza la identificación exacta de la versión del código inyectada.
5.2. Evidencias de Configuración Contable

Según los registros de logs analizados, una instalación estándar de localización española (v7.0.49) resulta en:

  • Plan Contable:  776 cuentas creadas (basado en el Plan para PYMES 2008).
  • Geodata:  Importación de 249 países y 37,867 códigos postales para España.
  • Impuestos:  Configuración de 64 registros de impuestos, incluyendo IVAs del 21%, 10% y 4%.
  • Ejercicios Fiscales:  Creación automática de ejercicios desde 2026 hasta 2030 (60 periodos contables).
5.3. Resolución de Problemas (Troubleshooting)
  • Errores de Rama:  Si no existe una rama para la versión específica (ej. 8.0), el motor busca automáticamente el tag más alto disponible.
  • Conflicto de Localización:  Si se intenta mezclar proveedores incompatibles, el sistema bloquea la operación para prevenir la corrupción de la base contable.