Luis
Gonzalez

The Problem

Odoo's standard security model restricts CRM and Sales document ownership to a single Salesperson field. At Fiberlux, multiple executives — Postventa, Fidelización, and others — needed to operate on the same customer account simultaneously.

The result: critical AccessError blocks on every cross-team operation, invoicing bottlenecks, and manual admin intervention required every 2–4 hours to restore access.

Architectural Solution

Designed a Linked Executives (EV) governance engine that extends Odoo's security framework via ir.rule inheritance and dynamic relational logic — without forking the core.

• Dynamic Security Bypass: Re-architected Personal Orders and Personal Order Lines base rules using dot-notation relational paths, enabling safe CRUD operations for secondary executives.
• Context-Aware Approval Dispatch: Built a dispatcher inside create_level_ids that inspects the operating uid and routes approvals to the correct team category — bypassing the account owner's commercial hierarchy when the creator is an EV.
• ORM Integrity Fix: Resolved unlink AccessError on order lines by bridging the relational domain: order_id.partner_id.linked_executive_ids.user_id — forcing an implicit JOIN through the contacts and EV tables at query time.
• Auto-follower Integration: Wired EVs into Odoo's messaging engine as automatic Followers, guaranteeing full lifecycle visibility without manual subscriptions.

The Problem

Fiberlux's invoicing workflow ran entirely inside Odoo — generating a single electronic invoice took ~2 minutes, with no async support and brittle handling of complex cases: credit sales, detracciones, USD/PEN multi-currency, and SUNAT delivery retries.

During billing peaks, the process saturated Odoo workers and blocked the entire ERP, creating SLA risk and manual intervention overhead for the operations team.

Architectural Solution

Built a standalone Django-based invoicing engine that replaces Odoo's invoicing core with a high-throughput, async-first pipeline integrated with the Nubefact (SUNAT) API.

• Async/Sync Dual Mode: Primary path uses async SUNAT submission with automatic synchronous fallback — guaranteeing delivery under API instability without manual retries.
• Concurrent Worker Pool: 10 parallel workers process batches simultaneously — enabling 50 invoices with embedded QR codes in ~35 seconds.
• Validation Engine V2: Full business rule coverage for detracciones, exportaciones, venta al crédito, IGV handling, and comprobantes in USD/PEN per SUNAT normativa.
• PDF + QR Generation: Transforms SUNAT XML responses into signed PDFs with embedded QR codes, automatically dispatched to customer + billing team via email.
• Retry & Audit Trail: Exponential backoff with configurable attempts; every state transition (pending → sent → acknowledged → failed) recorded atomically for compliance traceability.
• 100% Test Coverage: Full unit + integration test suite covering happy paths, API failures, retry exhaustion, and multi-currency edge cases before production deployment.

The Problem

Fiberlux's custom Odoo module synced telephony data (call recordings, transcripts, quality reports) from Five9's SFTP server into the ERP. The original implementation was fully synchronous — during large data loads, it blocked Odoo's worker processes company-wide, freezing CRM and invoicing operations simultaneously.

Additional issues: data inconsistencies between Five9 and Odoo, growing storage costs from unmanaged file accumulation, and fragile SFTP connectivity with no retry logic.

Architectural Solution

Re-engineered the entire sync module with a multi-threaded async architecture — decoupling heavy I/O from Odoo's request cycle entirely.

• Decoupled Threading: Migrated SFTP business logic to independent Python threads — achieving zero perceived latency for end users during mass synchronizations.
• Concurrency Control: Indexed boolean flags in PostgreSQL manage thread state and prevent race conditions across concurrent sync workers.
• SQL Optimization: B-Tree indexes on Many2one foreign keys + PostgreSQL views reduced query cost on 40k+ record tables for high-performance reporting.
• Batch Sanitization: Configurable days_to_sanitize parameter with batch processing — auto-purges stale files on schedule, achieving 30% storage reduction.
• Resilient SFTP Client: Re-engineered SFTP client using Fabric (replacing Paramiko) with hierarchical exception handling and automatic connection retry — handles network instability without operator intervention.
• Memory-Efficient Batch Governor: Implemented a configurable batch-size controller (e.g., 1,000 records) that terminates remote scanning immediately upon reaching the limit, preventing Odoo's RAM from hitting soft-limit thresholds during massive historical migrations.
• Forward-compatible Design: Architecture sized for projected 2026 data growth, with batch and thread scaling built in from the ground up.

The Challenge

Fiberlux operates a critical production ERP on Odoo v13 managing mass invoicing, CRM, telephony integration, and customer contracts — all with heavily customized modules built over years.

A hard v17 upgrade proved infeasible: custom modules rely on deprecated APIs, data volume is large, and any single downtime window would halt billing operations. A v17 migration was initially scoped but ultimately abandoned in favor of a full Django rewrite — giving full control over performance, testability, and architecture without Odoo ORM constraints.

Migration Strategy

Designed a phased extraction architecture — instead of a risky big-bang rewrite, critical business logic is progressively migrated to standalone Django services, reducing Odoo coupling with each iteration.

• Phase 1 — Stabilize v13: Resolved production deadlocks and RAM saturation by tuning Odoo worker count, memory limits, and PostgreSQL connection pooling. Deployed a "Testodoo" environment for safe mass validation before any production change.
• Phase 2 — Flat-table Bridge: Migrated the first 5 modules using intermediate flat tables as a compatibility layer — decoupling business logic from Odoo's ORM while maintaining data continuity during the transition period.
• Phase 3 — Extract to Django: Invoicing engine, Five9 sync, and EV governance fully migrated to standalone Django services with clean REST API boundaries — entirely decoupled from Odoo's core.
• Phase 4 — Containerization: Dockerizing v13 production base with environment parity between dev, staging, and production as the foundation for the full Django target.
• Current Status: Project advanced but currently paused — foundation, architecture standards, and critical module extractions are complete. Resumption planned with frontend collaboration (Angular) already underway by a colleague.

The Problem

Several critical Odoo and Django workflows exhibited unexplained latency under production load — invoicing generation, CRM report queries, and data sync operations were degrading progressively as data volume grew.

Without systematic profiling, bottleneck identification was guesswork: developers were optimizing the wrong paths while true hotspots remained undetected. The system had no baseline performance data and no methodology for continuous optimization.

Methodology & Solution

Implemented a systematic profiling pipeline using cProfile + SnakeViz to identify true hotspots with data — eliminating guesswork from optimization decisions.

• cProfile Instrumentation: Wrapped critical code paths with cProfile.Profile() context managers, capturing full call-stack timing data including cumulative and per-call execution times across all function invocations.
• SnakeViz Visualization: Rendered flame graphs and icicle charts to visually identify the highest-cost call chains — making it immediately clear which functions dominated execution time.
• N+1 Query Detection: Profiling revealed multiple N+1 patterns where ORM loops were issuing one DB query per record. Resolved by rewriting with select_related(), prefetch_related(), and bulk querysets — collapsing hundreds of queries into single optimized calls.
• Strategic Index Creation: Used EXPLAIN ANALYZE on the slowest queries to identify sequential scans on high-cardinality columns. Created B-Tree composite indexes on frequently filtered foreign keys and date ranges — turning multi-second scans into millisecond lookups.
• Script-level Refactoring: Several hotspots were Python-level inefficiencies — replaced nested loops with set-based lookups, eliminated redundant serialization calls, and moved heavy computations outside iteration contexts.
• Baseline & Regression Testing: Established benchmark scripts to measure before/after timings, ensuring optimizations held under realistic data volumes and preventing performance regressions in future deployments.