ERP

Ingeniería Odoo

Experiencia profesional de v13 a v19, con el mayor foco en v16–v19 Enterprise. Desarrollo de módulos custom, integraciones complejas, migraciones multi-versión y mantenimiento de sistemas en producción.

Odoo Enterprise v8 → v19 Python · PostgreSQL · QWeb 5+ yrs experience ↗

Cobertura de versiones

Primer contacto en v8 durante prácticas universitarias. Profesional desde v13. El historial de migraciones incluye el salto de v10 a v16 en un único proyecto.

Prácticas
v8 v10
Profesional
v13 v14 v15
Foco principal
v16 v17 v18 v19
Enterprise

Proyectos de migración multi-versión completados, incluyendo una instancia en producción migrada de v10 a v16 en un único proyecto.

Áreas de negocio

Áreas funcionales con conocimiento técnico y de procesos consolidado.

Cobertura principal
Sales Inventory Accounting Purchase Helpdesk POS HR & Planning
Periférico
eCommerce

Trabajo técnico

Qué se construye, depura, integra y despliega.

Desarrollo core

  • Full module development lifecycle
  • ORM & computed fields
  • Server actions & automated actions
  • Cron jobs
  • Direct SQL queries
  • Constraints & onchange logic

Reportes

  • QWeb templates (PDF & web)
  • account.report framework
  • XLSX custom reports
  • Custom invoice & document layouts

Integraciones

  • REST API controllers (inbound)
  • Outbound API integrations
  • Pentaho · Trusted Shops · OXID
  • Roomz · Quotapath
  • Bidirectional data sync patterns

Rendimiento y depuración

  • PostgreSQL query optimization
  • ORM profiling & N+1 detection
  • Production issue debugging
  • Index tuning & query planning

Infraestructura

  • Odoo.sh workflows
  • GitHub Actions CI/CD
  • Docker-based environments
  • Linux server management

Frontend

  • Owl component framework
  • POS frontend customizations
  • Website & eCommerce overrides
  • Modern JS tooling

Cómo construyo

Algunos principios que dan forma al trabajo.

Fácil de actualizar, antes que ingenioso. Si una personalización exige un esfuerzo heroico en la siguiente migración, estaba mal construida.

Límites de módulo que reflejan el dominio de negocio, no la línea de tiempo del desarrollo.

Integraciones diseñadas para fallar con claridad — con errores explícitos, sin corrupción silenciosa de datos.

PostgreSQL tratado como preocupación de primer nivel, no como un detalle pendiente cuando el módulo ya va lento.

Código legible por el siguiente desarrollador sin necesidad de una visita guiada.