rckrdmrd/erp-core
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
main
erp-core/docs/04-modelado/trazabilidad/VALIDACION-COBERTURA-ODOO.md

564 lines
21 KiB
Markdown
Raw Permalink Blame History

# VALIDACION DE COBERTURA VS ODOO
**Proyecto:** ERP Generic
**Fecha:** 2025-11-24
**Versión Odoo:** Community Edition v18.0
**Analizado por:** Architecture-Analyst
---
## Resumen Ejecutivo
### Métricas Globales
| Métrica | Valor |
|---------|-------|
| **Cobertura Total** | 78% |
| **Módulos Analizados** | 10 |
| **Gaps Críticos** | 12 |
| **Gaps Menores** | 18 |
| **Mejoras sobre Odoo** | 8 |
### Distribución de Cobertura por Módulo
| Módulo Odoo | Esquema ERP Generic | Cobertura | Estado |
|-------------|---------------------|-----------|--------|
| base | auth, core | 90% | ✅ Excelente |
| account | financial | 85% | ✅ Muy Bueno |
| stock | inventory | 80% | ✅ Bueno |
| purchase | purchase | 75% | ✅ Bueno |
| sale | sales | 75% | ✅ Bueno |
| analytic | analytics | 90% | ✅ Excelente |
| project | projects | 85% | ✅ Muy Bueno |
| hr | - | 0% | ❌ No Implementado |
| crm | - | 0% | ❌ No Implementado |
| mail | system | 70% | ⚠️ Parcial |
### Gaps Críticos Identificados
1. **HR Module**: Gestión completa de recursos humanos (empleados, contratos, nómina)
2. **CRM Module**: Pipeline de oportunidades y leads
3. **Mail Thread**: Followers/subscriptions por registro
4. **Partner Categories**: Categorías de partners
5. **Product Variants**: Gestión completa de variantes con atributos
6. **Stock Routes**: Rutas de abastecimiento automático
7. **Serial Number Tracking**: Tracking individual por serial
8. **Purchase Requisitions**: Proceso de requisición antes de PO
9. **Sale Order Templates**: Plantillas de órdenes de venta
10. **Project Portal**: Portal externo para clientes
11. **Timesheet Validation**: Aprobación de timesheets
12. **Multi-currency Rate Tables**: Tablas de tasas por fecha
---
## Por Módulo
### 1. BASE (auth + core schemas)
**Cobertura:** 90%
#### Modelos Implementados
| Modelo Odoo | Tabla ERP Generic | Estado |
|-------------|-------------------|--------|
| res.users | auth.users | ✅ Implementado |
| res.partner | core.partners | ✅ Implementado |
| res.company | auth.companies | ✅ Implementado |
| res.currency | core.currencies | ✅ Implementado |
| res.country | core.countries | ✅ Implementado |
| ir.attachment | core.attachments | ✅ Implementado |
| ir.sequence | core.sequences | ✅ Implementado |
| res.groups | auth.roles | ✅ Implementado (adaptado) |
| ir.model.access | auth.permissions | ✅ Implementado (RBAC) |
| uom.uom | core.uom | ✅ Implementado |
#### Gaps Identificados
- [ ] **GAP-BASE-001**: res.partner.category - Categorías de partners (prioridad: media)
- **Impacto**: No se pueden segmentar partners por categorías predefinidas
- **Workaround**: Usar tags genéricos de core.tags
- [ ] **GAP-BASE-002**: ir.cron - Tareas programadas/cron jobs (prioridad: alta)
- **Impacto**: No hay sistema nativo de tareas programadas
- **Recomendación**: Implementar con scheduler externo o agregar tabla scheduled_jobs
- [ ] **GAP-BASE-003**: ir.config_parameter - Parámetros de configuración global (prioridad: media)
- **Impacto**: Configuraciones hardcodeadas o en JSON settings
- **Workaround**: Usar JSONB settings en auth.tenants y auth.companies
#### Diferencias de Implementación
| Aspecto | Odoo | ERP Generic | Análisis |
|---------|------|-------------|----------|
| Multi-tenancy | Single DB, multi-company | Schema-level isolation + multi-company | ✅ Mejor en ERP Generic |
| Permisos | XML-based groups | RBAC con roles y permissions | ✅ Más flexible en ERP Generic |
| Partners | Único modelo polimórfico | Único modelo con flags (is_customer, is_supplier) | ✅ Igual, bien implementado |
| Attachments | Polimórfico | Polimórfico | ✅ Igual |
| Address | Campos en partner | Tabla separada addresses | ⚠️ Diferente, ambos válidos |
#### Mejoras sobre Odoo
1. **Multi-tenancy Nativo**: ERP Generic tiene aislamiento por schema, más seguro
2. **RBAC Moderno**: Sistema de permisos más granular y flexible
3. **RLS (Row Level Security)**: Seguridad a nivel de base de datos
4. **UUID Primary Keys**: Mejor para sistemas distribuidos
---
### 2. ACCOUNT (financial schema)
**Cobertura:** 85%
#### Modelos Implementados
| Modelo Odoo | Tabla ERP Generic | Estado |
|-------------|-------------------|--------|
| account.account | financial.accounts | ✅ Implementado |
| account.move | financial.journal_entries | ✅ Implementado |
| account.move.line | financial.journal_entry_lines | ✅ Implementado |
| account.journal | financial.journals | ✅ Implementado |
| account.tax | financial.taxes | ✅ Implementado |
| account.payment | financial.payments | ✅ Implementado |
| account.payment.term | financial.payment_terms | ✅ Implementado |
| account.fiscal.year | financial.fiscal_years | ✅ Implementado |
| account.fiscal.period | financial.fiscal_periods | ✅ Implementado |
| account.invoice | financial.invoices | ✅ Implementado |
| account.invoice.line | financial.invoice_lines | ✅ Implementado |
| account.bank.statement | financial.reconciliations | ✅ Implementado (adaptado) |
#### Gaps Identificados
- [ ] **GAP-ACCOUNT-001**: account.reconcile.model - Modelos de conciliación automática (prioridad: media)
- **Impacto**: Conciliación manual más lenta
- [ ] **GAP-ACCOUNT-002**: account.tax.group - Agrupación de impuestos (prioridad: baja)
- **Impacto**: Reportes de impuestos menos organizados
- [ ] **GAP-ACCOUNT-003**: account.analytic.distribution - Distribución analítica automática (prioridad: media)
- **Impacto**: Limitado en analytics.analytic_distributions pero falta automatización
#### Diferencias de Implementación
| Aspecto | Odoo | ERP Generic | Análisis |
|---------|------|-------------|----------|
| Move vs Entry | account.move | journal_entries | ✅ Misma funcionalidad |
| Tax Calculation | Python computed | Trigger-based | ⚠️ Odoo más flexible |
| Balance Validation | Python constraints | DB triggers | ✅ ERP Generic más robusto |
| Multi-currency | Native support | Native support | ✅ Igual |
#### Mejoras sobre Odoo
1. **Validación a Nivel DB**: Triggers garantizan integridad de partida doble
2. **Conciliación Bancaria**: Tabla dedicada para reconciliations
3. **Tracking Automático**: Sistema de change_log integrado
---
### 3. STOCK (inventory schema)
**Cobertura:** 80%
#### Modelos Implementados
| Modelo Odoo | Tabla ERP Generic | Estado |
|-------------|-------------------|--------|
| product.product | inventory.products | ✅ Implementado |
| product.template | inventory.products | ✅ Implementado (fusionado) |
| product.category | core.product_categories | ✅ Implementado |
| stock.warehouse | inventory.warehouses | ✅ Implementado |
| stock.location | inventory.locations | ✅ Implementado |
| stock.quant | inventory.stock_quants | ✅ Implementado |
| stock.move | inventory.stock_moves | ✅ Implementado |
| stock.picking | inventory.pickings | ✅ Implementado |
| stock.lot | inventory.lots | ✅ Implementado |
| stock.inventory | inventory.inventory_adjustments | ✅ Implementado |
#### Gaps Identificados
- [ ] **GAP-STOCK-001**: stock.route - Rutas de abastecimiento (prioridad: alta)
- **Impacto**: No hay automatización de reabastecimiento
- **Recomendación**: Agregar tabla stock_routes
- [ ] **GAP-STOCK-002**: stock.rule - Reglas de procurement (prioridad: alta)
- **Impacto**: Órdenes de compra/producción manuales
- [ ] **GAP-STOCK-003**: product.product (variantes) - Gestión completa de variantes (prioridad: media)
- **Impacto**: Tabla product_variants existe pero sin atributos configurables
- **Estado**: Parcialmente implementado
- [ ] **GAP-STOCK-004**: stock.picking.batch - Procesamiento por lotes (prioridad: baja)
- **Impacto**: Eficiencia en procesamiento de múltiples pickings
#### Diferencias de Implementación
| Aspecto | Odoo | ERP Generic | Análisis |
|---------|------|-------------|----------|
| Product Template | Separado de variant | Fusionado en products | ⚠️ Odoo más flexible para variantes |
| Stock Quants | Quants system | Quants system | ✅ Igual, bien implementado |
| Valuation | FIFO/LIFO/AVG | FIFO/AVG/STD | ✅ Comparable |
| Serial Tracking | Lot & Serial | Lot only | ❌ GAP importante |
#### Mejoras sobre Odoo
1. **Jerarquía de Ubicaciones**: Campo complete_name generado automáticamente
2. **Reserved Quantity**: Campo calculado available_quantity
---
### 4. PURCHASE (purchase schema)
**Cobertura:** 75%
#### Modelos Implementados
| Modelo Odoo | Tabla ERP Generic | Estado |
|-------------|-------------------|--------|
| purchase.order | purchase.purchase_orders | ✅ Implementado |
| purchase.order.line | purchase.purchase_order_lines | ✅ Implementado |
| purchase.requisition | purchase.rfqs | ✅ Implementado (adaptado) |
| product.supplierinfo | purchase.vendor_pricelists | ✅ Implementado |
| purchase.agreement | purchase.purchase_agreements | ✅ Implementado |
#### Gaps Identificados
- [ ] **GAP-PURCHASE-001**: purchase.requisition (full) - Proceso completo de requisición (prioridad: media)
- **Impacto**: Tabla rfqs no cubre todo el flujo de requisiciones
- **Estado**: Parcialmente implementado
- [ ] **GAP-PURCHASE-002**: purchase.bill.union - Vista unificada de facturas (prioridad: baja)
- **Impacto**: Queries más complejas
- [ ] **GAP-PURCHASE-003**: purchase.order.type - Tipos de órdenes de compra (prioridad: baja)
#### Diferencias de Implementación
| Aspecto | Odoo | ERP Generic | Análisis |
|---------|------|-------------|----------|
| RFQ Process | Complejo | Simplificado | ⚠️ Odoo más completo |
| Vendor Evaluation | Module add-on | Built-in table | ✅ ERP Generic incluido |
| Agreement Types | Blanket order | price/discount/blanket | ✅ ERP Generic más flexible |
#### Mejoras sobre Odoo
1. **Vendor Evaluations**: Tabla dedicada para evaluación de proveedores
2. **Agreement Types**: Enum más específico
---
### 5. SALE (sales schema)
**Cobertura:** 75%
#### Modelos Implementados
| Modelo Odoo | Tabla ERP Generic | Estado |
|-------------|-------------------|--------|
| sale.order | sales.sales_orders | ✅ Implementado |
| sale.order.line | sales.sales_order_lines | ✅ Implementado |
| product.pricelist | sales.pricelists | ✅ Implementado |
| product.pricelist.item | sales.pricelist_items | ✅ Implementado |
| sale.order.template | - | ❌ No implementado |
| crm.team | sales.sales_teams | ✅ Implementado |
#### Gaps Identificados
- [ ] **GAP-SALE-001**: sale.order.template - Plantillas de órdenes de venta (prioridad: media)
- **Impacto**: No se pueden reutilizar configuraciones de orden
- [ ] **GAP-SALE-002**: sale.order.option - Opciones opcionales en cotización (prioridad: baja)
- **Impacto**: Cotizaciones menos flexibles
- [ ] **GAP-SALE-003**: Quotations como tabla separada vs estado en sale_order (prioridad: baja)
- **Análisis**: ERP Generic tiene quotations separado, Odoo usa estados
#### Diferencias de Implementación
| Aspecto | Odoo | ERP Generic | Análisis |
|---------|------|-------------|----------|
| Quotations | Estado en sale.order | Tabla separada quotations | ⚠️ Diferente enfoque, ambos válidos |
| Electronic Signature | Add-on | Built-in | ✅ ERP Generic incluido |
| Customer Groups | Tags | Tabla dedicada | ✅ ERP Generic más estructurado |
#### Mejoras sobre Odoo
1. **Quotations Separadas**: Tabla dedicada para gestión de cotizaciones
2. **Firma Electrónica Built-in**: Campos signature, signature_date, signature_ip
3. **Customer Groups**: Gestión de grupos con descuentos
---
### 6. ANALYTIC (analytics schema)
**Cobertura:** 90%
#### Modelos Implementados
| Modelo Odoo | Tabla ERP Generic | Estado |
|-------------|-------------------|--------|
| account.analytic.account | analytics.analytic_accounts | ✅ Implementado |
| account.analytic.line | analytics.analytic_lines | ✅ Implementado |
| account.analytic.plan | analytics.analytic_plans | ✅ Implementado |
| account.analytic.tag | analytics.analytic_tags | ✅ Implementado |
| account.analytic.distribution | analytics.analytic_distributions | ✅ Implementado |
#### Gaps Identificados
- [ ] **GAP-ANALYTIC-001**: account.analytic.group - Agrupación de cuentas analíticas (prioridad: baja)
#### Diferencias de Implementación
| Aspecto | Odoo | ERP Generic | Análisis |
|---------|------|-------------|----------|
| Multi-dimensional | Planes analíticos | Planes analíticos | ✅ Igual |
| Distribution | Percentage-based | Percentage-based | ✅ Igual |
| Cost Centers | No dedicado | Tabla cost_centers | ✅ ERP Generic mejor |
#### Mejoras sobre Odoo
1. **Cost Centers**: Tabla dedicada con presupuestos
2. **Balance View**: Vista analytic_balance_view con varianza presupuestal
3. **Validación 100%**: Trigger para validar distribución no exceda 100%
---
### 7. PROJECT (projects schema)
**Cobertura:** 85%
#### Modelos Implementados
| Modelo Odoo | Tabla ERP Generic | Estado |
|-------------|-------------------|--------|
| project.project | projects.projects | ✅ Implementado |
| project.task | projects.tasks | ✅ Implementado |
| project.task.type | projects.project_stages | ✅ Implementado |
| project.milestone | projects.milestones | ✅ Implementado |
| project.task.dependency | projects.task_dependencies | ✅ Implementado |
| project.tags | projects.task_tags | ✅ Implementado |
| account.analytic.line (timesheet) | projects.timesheets | ✅ Implementado |
| project.task.checklist | projects.task_checklists | ✅ Implementado |
#### Gaps Identificados
- [ ] **GAP-PROJECT-001**: project.update - Actualizaciones periódicas de proyecto (prioridad: media)
- **Impacto**: No hay registro formal de status updates
- [ ] **GAP-PROJECT-002**: project.portal - Portal para clientes externos (prioridad: media)
- **Impacto**: Clientes no pueden ver progreso del proyecto
- [ ] **GAP-PROJECT-003**: project.favorite.user - Favoritos por usuario (prioridad: baja)
#### Diferencias de Implementación
| Aspecto | Odoo | ERP Generic | Análisis |
|---------|------|-------------|----------|
| Task Dependencies | Sí | Sí con tipos y validación circular | ✅ ERP Generic mejor |
| Timesheets | account.analytic.line | Tabla dedicada | ✅ ERP Generic más claro |
| Templates | project.project (is_template) | Tabla project_templates | ✅ ERP Generic mejor |
#### Mejoras sobre Odoo
1. **Dependency Types**: finish_to_start, start_to_start, etc.
2. **Circular Dependency Prevention**: Trigger automático
3. **Task Checklists**: Built-in, no requiere módulo adicional
4. **Project Templates**: Tabla dedicada con template_data JSON
---
### 8. HR (NO IMPLEMENTADO)
**Cobertura:** 0%
#### Modelos de Odoo NO Implementados
| Modelo Odoo | Estado | Prioridad |
|-------------|--------|-----------|
| hr.employee | ❌ No implementado | Alta |
| hr.contract | ❌ No implementado | Alta |
| hr.department | ❌ No implementado | Media |
| hr.job | ❌ No implementado | Media |
| hr.attendance | ❌ No implementado | Media |
| hr.leave | ❌ No implementado | Media |
| hr.expense | ❌ No implementado | Media |
#### Gap Crítico
- [ ] **GAP-HR-001**: Módulo completo de HR (prioridad: alta)
- **Impacto**: No se puede gestionar empleados, contratos, asistencia, vacaciones
- **Recomendación**: Implementar schema hr con tablas básicas
- **Dependencias**: Afecta timesheets (falta employee_id FK)
#### Workaround Temporal
- Usar `core.partners` con flag `is_employee = true`
- Usar `auth.users` para usuarios-empleados
- Crear tabla externa para contratos si es crítico
---
### 9. CRM (NO IMPLEMENTADO)
**Cobertura:** 0%
#### Modelos de Odoo NO Implementados
| Modelo Odoo | Estado | Prioridad |
|-------------|--------|-----------|
| crm.lead | ❌ No implementado | Alta |
| crm.stage | ❌ No implementado | Alta |
| crm.team | ✅ Implementado como sales.sales_teams | Media |
| crm.lost.reason | ❌ No implementado | Baja |
#### Gap Crítico
- [ ] **GAP-CRM-001**: Pipeline de leads/oportunidades (prioridad: alta)
- **Impacto**: No hay gestión de prospectos antes de cotización
- **Recomendación**: Agregar schema crm o extender sales
- [ ] **GAP-CRM-002**: Actividades y seguimiento (prioridad: media)
- **Estado**: Parcialmente en system.activities pero no vinculado a leads
#### Workaround Temporal
- Usar `sales.quotations` con status='draft' como leads
- Usar `system.activities` para seguimiento
---
### 10. MAIL (system schema - Parcial)
**Cobertura:** 70%
#### Modelos Implementados
| Modelo Odoo | Tabla ERP Generic | Estado |
|-------------|-------------------|--------|
| mail.message | system.messages | ✅ Implementado |
| mail.followers | system.message_followers | ✅ Implementado |
| mail.activity | system.activities | ✅ Implementado |
| mail.template | system.message_templates | ✅ Implementado |
| mail.tracking.value | system.change_log | ✅ Implementado (mejor) |
| mail.mail | system.email_queue | ✅ Implementado |
#### Gaps Identificados
- [ ] **GAP-MAIL-001**: mail.channel - Canales de chat (prioridad: baja)
- **Impacto**: No hay chat interno
- [ ] **GAP-MAIL-002**: mail.notification - Notificaciones detalladas por mensaje (prioridad: media)
- **Estado**: Hay system.notifications pero no vinculadas a messages
- [ ] **GAP-MAIL-003**: mail.alias - Aliases de email (prioridad: baja)
#### Diferencias de Implementación
| Aspecto | Odoo | ERP Generic | Análisis |
|---------|------|-------------|----------|
| Tracking | mail.tracking.value | system.change_log + field_tracking_config | ✅ ERP Generic mejor estructurado |
| Followers | mail.followers | message_followers | ✅ Igual |
| Activities | mail.activity | system.activities | ✅ Igual |
| Email Queue | mail.mail | system.email_queue | ✅ Igual |
#### Mejoras sobre Odoo
1. **Field Tracking Config**: Tabla de configuración de qué campos trackear
2. **Change Log**: Historial más estructurado con old_value/new_value
3. **Tracking Trigger**: Función genérica `track_field_changes()` reutilizable
4. **Dashboard System**: Dashboards y widgets configurables
---
## Análisis de Arquitectura
### Patrones Adoptados de Odoo
✅ **Adoptados Correctamente:**
1. Partner único polimórfico (customers, suppliers, employees)
2. Contabilidad analítica multi-dimensional
3. Sistema de permisos por roles
4. Mail thread pattern (tracking de cambios)
5. Polimorfismo en attachments, notes, messages
6. Jerarquías (partners, locations, categories)
7. Multi-moneda nativo
8. Soft deletes con deleted_at
✅ **Mejorados sobre Odoo:**
1. Multi-tenancy con schema isolation
2. RLS (Row Level Security) a nivel DB
3. UUID primary keys
4. Triggers para validación de integridad
5. Field tracking configurado por tabla
6. Tablas dedicadas (cost_centers, customer_groups, vendor_evaluations)
⚠️ **Pendientes de Implementar:**
1. HR Module completo
2. CRM Module completo
3. Stock routes y procurement
4. Serial number tracking individual
5. Product attributes y variantes configurables
6. Scheduled tasks (ir.cron)
---
## Recomendaciones Prioritarias
### Corto Plazo (Sprint 1-2)
1. **GAP-HR-001**: Implementar módulo HR básico
- Tablas: hr.employees, hr.contracts, hr.departments
- Integrar employee_id en timesheets y analytic_lines
2. **GAP-STOCK-001**: Implementar stock.routes básico
- Automatización de reabastecimiento
3. **GAP-MAIL-002**: Vincular notifications con messages
- Mejorar sistema de notificaciones
### Medio Plazo (Sprint 3-6)
4. **GAP-CRM-001**: Implementar módulo CRM básico
- Pipeline de leads/oportunidades
5. **GAP-BASE-002**: Sistema de tareas programadas
- Tabla scheduled_jobs o integración con cron externo
6. **GAP-STOCK-003**: Completar product variants
- Atributos configurables
### Largo Plazo (Post-MVP)
7. Mejorar portal externo para clientes
8. Implementar serial number tracking
9. Agregar purchase requisitions completo
10. Módulos avanzados de reporting
---
## Conclusiones
### Fortalezas del ERP Generic
1. **Arquitectura Moderna**: Multi-tenancy, UUID, RLS
2. **Cobertura Core Sólida**: 78% de cobertura en módulos principales
3. **Mejoras sobre Odoo**: Tracking, cost centers, validaciones DB
4. **Buena Base**: auth, core, financial, analytics muy completos
### Áreas de Mejora
1. **HR Module**: Gap crítico, necesario para empresas
2. **CRM**: Importante para pipeline de ventas
3. **Stock Avanzado**: Routes, procurement, serial tracking
4. **Portal**: Acceso externo para clientes/proveedores
### Decisión Estratégica
El ERP Generic tiene una **base sólida** que cubre el 78% de funcionalidades core de Odoo, con **mejoras arquitectónicas significativas**. Los gaps identificados son manejables y pueden implementarse por fases según prioridad del negocio.
**Recomendación**: Proceder con el desarrollo, priorizando implementación de HR básico y mejoras en stock en los próximos sprints.
---
**Generado por:** Architecture-Analyst
**Fecha:** 2025-11-24
**Versión:** 1.0.0
Reference in New Issue View Git Blame Copy Permalink