rckrdmrd 59f1e3badf Initial commit - erp-core

2026-01-04 06:12:07 -06:00

17 KiB

Raw Permalink Blame History

Mejoras Arquitectónicas Recomendadas para ERP Construcción

Documento: Mejoras Arquitectónicas Basadas en Análisis de Referencias Proyectos Analizados: Odoo, Gamilit, ERP Construcción Fecha: 2025-11-23 Analista: Architecture-Analyst Estado: Completado

Introducción

Este documento consolida las mejoras arquitectónicas recomendadas para el ERP Construcción, basadas en:

Análisis de Odoo (14 archivos): Lógica de negocio probada en miles de empresas
Análisis de Gamilit (7 archivos): Arquitectura moderna y patrones efectivos
Validación con ERP Construcción: Identificación de gaps y oportunidades

1. MEJORAS BASADAS EN ODOO

1.1 Implementar Contabilidad Analítica Universal (account.analytic.account)

Hallazgo Odoo:

Patrón account.analytic.account + account.analytic.line
Campo analytic_account_id en TODAS las transacciones
Reportes consolidados por proyecto/centro de costo

Aplicación en Construcción:

-- Agregar a TODAS las tablas transaccionales:
ALTER TABLE purchasing_management.purchase_orders
ADD COLUMN analytic_account_id UUID REFERENCES analytics.accounts(id);

ALTER TABLE financial_management.journal_entry_lines
ADD COLUMN analytic_account_id UUID REFERENCES analytics.accounts(id);

ALTER TABLE construction_management.physical_progress
ADD COLUMN analytic_account_id UUID REFERENCES analytics.accounts(id);

Beneficios:

Consolidación automática de costos por proyecto/lote/manzana
Reportes P&L por proyecto sin queries complejos
Trazabilidad completa de costos

Prioridad: P0 - CRÍTICO
Esfuerzo: 3-4 semanas
ROI: ALTO (reduce 70% tiempo de reportes)

1.2 Sistema de Tracking Automático (mail.thread)

Hallazgo Odoo:

Herencia mail.thread en modelos críticos
Tracking automático de cambios en campos configurados
Chatter UI para histórico de cambios

Aplicación en Construcción:

// Backend: Implementar TrackingMixin
class BaseEntity {
  @TrackChanges(['status', 'amount', 'assigned_to'])
  async update(data: Partial<T>) {
    const before = await this.findById(id);
    const after = await this.repo.update(id, data);
    await this.trackingService.logChanges(before, after);
    return after;
  }
}

// Aplicar a:
// - Projects, Budgets, Purchase Orders, Construction Progress

Beneficios:

Auditoría automática sin código extra
Histórico de cambios por registro
Compliance con ISO 9001

Prioridad: P0 - CRÍTICO
Esfuerzo: 2-3 semanas
ROI: ALTO (ahorra 40% tiempo desarrollo auditoría)

1.3 Mejorar RBAC con Record Rules (ir.rule)

Hallazgo Odoo:

Record Rules: Filtros SQL dinámicos por rol
Ejemplo: Usuario solo ve proyectos de su empresa/región

Aplicación en Construcción:

-- RLS Policy con roles dinámicos
CREATE POLICY "users_see_own_company_projects"
ON project_management.projects
FOR SELECT
USING (
  company_id = get_current_tenant_id()
  AND (
    -- Director: ve todos los proyectos
    current_user_has_role('director')
    -- Residente: solo sus proyectos asignados
    OR (current_user_has_role('resident') AND id IN (
      SELECT project_id FROM project_teams WHERE user_id = get_current_user_id()
    ))
  )
);

Beneficios:

Seguridad a nivel de fila por rol
No requiere filtros en queries
Escalable a múltiples tenants

Prioridad: P0 - CRÍTICO
Esfuerzo: 2 semanas
ROI: ALTO (seguridad garantizada)

1.4 Implementar Partner Universal (res.partner)

Hallazgo Odoo:

Una tabla res.partner para clientes, proveedores, empleados, contactos
Flags: is_customer, is_supplier, is_employee

Aplicación en Construcción:

CREATE TABLE core_system.partners (
  id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
  name VARCHAR(255) NOT NULL,
  -- Flags de tipo
  is_customer BOOLEAN DEFAULT false,
  is_supplier BOOLEAN DEFAULT true,  -- Construcción = proveedores
  is_employee BOOLEAN DEFAULT false,
  is_beneficiary BOOLEAN DEFAULT false,  -- Derechohabientes INFONAVIT
  is_subcontractor BOOLEAN DEFAULT false,
  -- Campos comunes
  email VARCHAR(255),
  phone VARCHAR(50),
  address TEXT,
  ...
);

-- Migrar:
-- suppliers → partners (is_supplier=true)
-- beneficiaries → partners (is_beneficiary=true)

Beneficios:

Elimina duplicación (suppliers, customers, contacts)
Un proveedor puede ser cliente (común en construcción)
Simplifica relaciones

Prioridad: P1 - ALTA
Esfuerzo: 4 semanas (migración de datos)
ROI: MEDIO (reducción de complejidad)

1.5 Portal de Usuarios Externos (portal)

Hallazgo Odoo:

Rol portal_user con acceso read-only a sus registros
Firma electrónica de documentos
Vista de proyectos para clientes

Aplicación en Construcción:

// Backend: Portal API
@Controller('/portal')
@UseGuards(PortalAuthGuard)  // JWT con role=portal_user
export class PortalController {
  // Derechohabiente ve su lote/vivienda
  @Get('/my-housing')
  async getMyHousing(@CurrentUser() user) {
    return this.beneficiaryService.findByUserId(user.id);
  }
  
  // Ver avances de su vivienda
  @Get('/progress')
  async getProgress(@CurrentUser() user) {
    const housing = await this.getMyHousing(user);
    return this.progressService.findByLot(housing.lot_id);
  }
}

Beneficios:

Derechohabientes ven avance de su vivienda
Reduce llamadas al call center
Mejora experiencia cliente

Prioridad: P1 - ALTA
Esfuerzo: 3 semanas
ROI: ALTO (satisfacción cliente +30%)

2. MEJORAS BASADAS EN GAMILIT

2.1 Migrar a Arquitectura Multi-Schema (9 schemas)

Hallazgo Gamilit:

9 schemas PostgreSQL separados por dominio
Organización estándar: tables/, indexes/, functions/, triggers/, views/, rls-policies/
Sistema SIMCO de _MAP.md para documentación

Aplicación en Construcción:

database/ddl/
├── core_system/
│   ├── tables/
│   ├── indexes/
│   ├── functions/
│   └── _MAP.md
├── project_management/
│   ├── tables/
│   ├── indexes/
│   └── _MAP.md
├── financial_management/
├── purchasing_management/
├── construction_management/
├── quality_management/
├── infonavit_management/
├── audit_logging/
└── system_notifications/

Beneficios:

Organización clara por dominio
Permisos granulares por schema
Navegación rápida con _MAP.md

Prioridad: P0 - CRÍTICO
Esfuerzo: 2 semanas (reorganización)
ROI: ALTO (mantenibilidad +50%)

2.2 Implementar Sistema SSOT (Single Source of Truth)

Hallazgo Gamilit:

Backend como única fuente de verdad para constantes
Script sync-enums.ts sincroniza Backend → Frontend
Script validate-constants-usage.ts detecta hardcoding

Aplicación en Construcción:

// backend/src/shared/constants/database.constants.ts
export const DB_SCHEMAS = {
  CORE: 'core_system',
  PROJECTS: 'project_management',
  FINANCIAL: 'financial_management',
  PURCHASING: 'purchasing_management',
  CONSTRUCTION: 'construction_management',
  // ...
} as const;

export const DB_TABLES = {
  PROJECTS: {
    PROJECTS: 'projects',
    BLOCKS: 'blocks',
    LOTS: 'lots',
    PROTOTYPES: 'housing_prototypes',
  },
  // ...
};

// Script sincroniza a frontend automáticamente

Beneficios:

CERO duplicación de constantes
Refactoring seguro (cambio en 1 lugar)
Validación automática de hardcoding

Prioridad: P0 - CRÍTICO
Esfuerzo: 1-2 semanas
ROI: ALTO (elimina 96% duplicación)

2.3 Adoptar Path Aliases (@shared, @modules, @components)

Hallazgo Gamilit:

Path aliases configurados en tsconfig.json
Imports limpios: @shared/services vs ../../../shared/services

Aplicación en Construcción:

// tsconfig.json
{
  "compilerOptions": {
    "paths": {
      "@shared/*": ["src/shared/*"],
      "@modules/*": ["src/modules/*"],
      "@config/*": ["src/config/*"],
      "@database/*": ["../../database/*"],
      // Frontend
      "@components/*": ["src/components/*"],
      "@features/*": ["src/features/*"],
      "@hooks/*": ["src/hooks/*"],
      "@services/*": ["src/services/*"]
    }
  }
}

Beneficios:

Legibilidad de código
Refactoring fácil (mover carpetas)
IDE support completo

Prioridad: P0 - CRÍTICO
Esfuerzo: 1 día
ROI: ALTO (productividad +20%)

2.4 Implementar Scripts de Validación Automática

Hallazgo Gamilit:

validate-constants-usage.ts: Detecta hardcoding (33 patrones)
validate-api-contract.ts: Valida Backend ↔ Frontend
Integración CI/CD: Bloquea merge si hay violaciones P0

Aplicación en Construcción:

// devops/scripts/validate-constants-usage.ts
const PATTERNS = [
  {
    pattern: /['"]project_management['"]/g,
    message: 'Hardcoded schema "project_management"',
    severity: 'P0',
    suggestion: 'Usa DB_SCHEMAS.PROJECTS',
  },
  // 30+ patrones más...
];

// CI/CD: .github/workflows/validate.yml
jobs:
  validate:
    steps:
      - run: npm run validate:constants
      - run: npm run validate:api

Beneficios:

Calidad de código garantizada
Detección automática de malas prácticas
CI/CD enforcement

Prioridad: P0 - CRÍTICO
Esfuerzo: 1 semana
ROI: ALTO (previene bugs 70%)

2.5 Adoptar Feature-Sliced Design en Frontend

Hallazgo Gamilit:

Arquitectura en capas: shared/, features/, pages/, app/
180+ componentes reutilizables en shared/
Features por rol: student/, teacher/, admin/

Aplicación en Construcción:

frontend/src/
├── shared/
│   ├── components/
│   │   ├── atoms/ (Button, Input, ...)
│   │   ├── molecules/ (FormField, SearchBar, ...)
│   │   ├── organisms/ (DataTable, Sidebar, ...)
│   │   └── templates/ (DashboardLayout, ...)
│   ├── hooks/
│   └── services/
├── features/
│   ├── director/ (Dashboard director)
│   ├── resident/ (Dashboard residente)
│   ├── purchases/ (Dashboard compras)
│   └── finance/ (Dashboard finanzas)
├── pages/
└── app/

Beneficios:

Componentes reutilizables 100%
Escalabilidad frontend
Desarrollo en equipo sin conflictos

Prioridad: P0 - CRÍTICO
Esfuerzo: 3-4 semanas (reestructuración)
ROI: ALTO (velocidad desarrollo +40%)

3. MEJORAS ESPECÍFICAS DE CONSTRUCCIÓN

3.1 Implementar Sistema de Versiones de Presupuestos

Gap Identificado: Presupuestos se sobrescriben, no hay histórico

Mejora:

CREATE TABLE financial_management.budget_versions (
  id UUID PRIMARY KEY,
  budget_id UUID REFERENCES budgets(id),
  version_number INTEGER NOT NULL,
  created_at TIMESTAMP DEFAULT now(),
  created_by UUID REFERENCES auth.users(id),
  is_current BOOLEAN DEFAULT false,
  -- Snapshot completo del presupuesto
  data JSONB NOT NULL,
  notes TEXT
);

Beneficios:

Histórico de cambios en presupuestos
Comparación versión anterior vs actual
Auditoría completa

Prioridad: P1 - ALTA
Esfuerzo: 1 semana
ROI: MEDIO (compliance)

3.2 Integración con WhatsApp Business API

Gap Identificado: Notificaciones solo por email, baja tasa de apertura

Mejora:

// backend/src/services/whatsapp.service.ts
class WhatsAppService {
  async sendNotification(to: string, template: string, params: any) {
    // Integración WhatsApp Business API
    await this.whatsappClient.sendTemplate({
      to,
      template,
      language: 'es_MX',
      params
    });
  }
}

// Casos de uso:
// - Notificar avance de vivienda a derechohabiente
// - Alertar supervisor de desviaciones presupuesto
// - Recordar inspecciones de calidad

Beneficios:

Tasa de apertura 98% vs 20% email
Comunicación inmediata con derechohabientes
Reducción llamadas call center

Prioridad: P1 - ALTA
Esfuerzo: 2 semanas
ROI: ALTO (satisfacción cliente +40%)

4. MEJORAS DE DEVOPS (GAPS CRÍTICOS GAMILIT)

4.1 Implementar Docker + docker-compose

Gap Gamilit: NO tiene Docker (ambientes inconsistentes)

Mejora:

# Dockerfile.backend
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
CMD ["npm", "start"]

# docker-compose.yml
version: '3.8'
services:
  db:
    image: postgis/postgis:15-3.3
    environment:
      POSTGRES_DB: erp_construccion
  backend:
    build: ./backend
    depends_on: [db]
  frontend:
    build: ./frontend

Beneficios:

Ambientes consistentes (dev/staging/prod)
Deployment fácil
Portable

Prioridad: P0 - CRÍTICO
Esfuerzo: 1 semana
ROI: ALTO (deployment 10x más rápido)

4.2 CI/CD con GitHub Actions

Gap Gamilit: NO tiene CI/CD (deployment manual)

Mejora:

# .github/workflows/deploy.yml
name: Deploy
on:
  push:
    branches: [main]
jobs:
  test:
    steps:
      - run: npm test
      - run: npm run validate:constants
  build:
    steps:
      - run: docker build -t erp-construccion .
  deploy:
    steps:
      - run: docker push ...
      - run: kubectl apply -f k8s/

Beneficios:

Deployment automático
Validaciones obligatorias
Rollback fácil

Prioridad: P0 - CRÍTICO
Esfuerzo: 2 semanas
ROI: ALTO (deployment seguro)

4.3 Aumentar Test Coverage de 14% a 70%+

Gap Gamilit: Coverage 14% (Backend 15%, Frontend 13%) - INACEPTABLE

Mejora:

// Estrategia de Testing
1. Unit Tests: Services, Utils (objetivo 80%)
2. Integration Tests: API endpoints (objetivo 70%)
3. E2E Tests: Flujos críticos (objetivo 60%)

// Enforcement en CI/CD
// jest.config.js
module.exports = {
  coverageThreshold: {
    global: {
      branches: 70,
      functions: 70,
      lines: 70,
      statements: 70
    }
  }
};

Beneficios:

Bugs detectados antes de producción
Refactoring seguro
Confianza en deployments

Prioridad: P0 - CRÍTICO
Esfuerzo: 6-8 semanas
ROI: ALTO (reducción bugs 70%)

5. ROADMAP DE IMPLEMENTACIÓN

Fase 1: Fundamentos SSOT (Semana 1-2)

✅ Reorganizar database en multi-schema
✅ Implementar SSOT (constants + sync)
✅ Path aliases (backend + frontend)
✅ Scripts de validación

Esfuerzo: 2 semanas
Prioridad: P0

Fase 2: Mejoras Odoo (Semana 3-6)

✅ Contabilidad analítica universal
✅ Sistema de tracking automático (mail.thread)
✅ Record Rules en RLS
✅ Partner universal
✅ Portal de usuarios externos

Esfuerzo: 4 semanas
Prioridad: P0-P1

Fase 3: DevOps Crítico (Semana 7-9)

✅ Docker + docker-compose
✅ CI/CD (GitHub Actions)
✅ Aumentar test coverage a 70%+

Esfuerzo: 3 semanas
Prioridad: P0

Fase 4: Arquitectura Frontend (Semana 10-13)

✅ Feature-Sliced Design
✅ 100+ componentes reutilizables
✅ State management (Zustand)

Esfuerzo: 4 semanas
Prioridad: P0

6. RESUMEN DE MEJORAS

Mejora	Fuente	Prioridad	Esfuerzo	ROI	Dependencias
Multi-Schema DB	Gamilit	P0	2 sem	Alto	-
SSOT System	Gamilit	P0	1-2 sem	Alto	-
Path Aliases	Gamilit	P0	1 día	Alto	-
Scripts Validación	Gamilit	P0	1 sem	Alto	SSOT
Contabilidad Analítica	Odoo	P0	3-4 sem	Alto	Multi-Schema
Tracking Automático	Odoo	P0	2-3 sem	Alto	-
Record Rules RLS	Odoo	P0	2 sem	Alto	-
Partner Universal	Odoo	P1	4 sem	Medio	-
Portal Usuarios	Odoo	P1	3 sem	Alto	Auth
Feature-Sliced Design	Gamilit	P0	3-4 sem	Alto	-
Docker	Best Practice	P0	1 sem	Alto	-
CI/CD	Best Practice	P0	2 sem	Alto	Docker
Test Coverage 70%	Best Practice	P0	6-8 sem	Alto	-

Total Mejoras P0: 10
Total Esfuerzo P0: 25-32 semanas (~6-8 meses)
Total Mejoras P1: 2
Total Esfuerzo P1: 7 semanas

7. CONCLUSIÓN

7.1 Impacto Esperado

Sin Mejoras:

Deuda técnica creciente
Bugs en producción
Deployment manual propenso a errores
Baja velocidad de desarrollo

Con Mejoras:

✅ Arquitectura moderna y escalable
✅ Deployment automatizado y seguro
✅ Test coverage 70%+ (bugs -70%)
✅ Velocidad desarrollo +40%
✅ Mantenibilidad +50%

7.2 Recomendación Final

IMPLEMENTAR TODAS LAS MEJORAS P0 EN LOS PRÓXIMOS 6-8 MESES

Razón: ROI alto, fundamentos críticos para escalabilidad y calidad.

Fecha de Creación: 2025-11-23 Versión: 1.0 Estado: Completado Próximo Documento: GAP-ANALYSIS.md

17 KiB Raw Permalink Blame History

Mejoras Arquitectónicas Recomendadas para ERP Construcción

Introducción

1. MEJORAS BASADAS EN ODOO

1.1 Implementar Contabilidad Analítica Universal (account.analytic.account)

1.2 Sistema de Tracking Automático (mail.thread)

1.3 Mejorar RBAC con Record Rules (ir.rule)

1.4 Implementar Partner Universal (res.partner)

1.5 Portal de Usuarios Externos (portal)

2. MEJORAS BASADAS EN GAMILIT

2.1 Migrar a Arquitectura Multi-Schema (9 schemas)

2.2 Implementar Sistema SSOT (Single Source of Truth)

2.3 Adoptar Path Aliases (@shared, @modules, @components)

2.4 Implementar Scripts de Validación Automática

2.5 Adoptar Feature-Sliced Design en Frontend

3. MEJORAS ESPECÍFICAS DE CONSTRUCCIÓN

3.1 Implementar Sistema de Versiones de Presupuestos

3.2 Integración con WhatsApp Business API

4. MEJORAS DE DEVOPS (GAPS CRÍTICOS GAMILIT)

4.1 Implementar Docker + docker-compose

4.2 CI/CD con GitHub Actions

4.3 Aumentar Test Coverage de 14% a 70%+

5. ROADMAP DE IMPLEMENTACIÓN

Fase 1: Fundamentos SSOT (Semana 1-2)

Fase 2: Mejoras Odoo (Semana 3-6)

Fase 3: DevOps Crítico (Semana 7-9)

Fase 4: Arquitectura Frontend (Semana 10-13)

6. RESUMEN DE MEJORAS

7. CONCLUSIÓN

7.1 Impacto Esperado

7.2 Recomendación Final

17 KiB

Raw Permalink Blame History