Saltar a contenido

Análisis: Estructura de Receptor Extranjero DGI vs Implementación Actual

🔍 Problema Identificado

Issue: Existe duplicación y incompletitud en los campos de receptor extranjero. La implementación actual no utiliza completamente la estructura B406-B416 de la ficha técnica DGI.

📋 Campos Actuales vs DGI B406-B416

Implementación Actual (Incompleta)

// Caso 3: Extranjero - Implementación actual
'gIdExt' => [
    'dIdExt' => $this->receptor_pasaporteIdentidadExtranjera,    // Solo pasaporte
    'dPaisExt' => $receptorPaisNacionalidad?->name ?: null,      // Solo país nacionalidad
],

Según Ficha Técnica DGI (B406-B416)

// Estructura COMPLETA según DGI
'gIdExt' => [
    'cTipoId' => $this->tipoIdentificacionExtranjero,           // B408 - Tipo identificación
    'dIdExt' => $this->numeroIdentificacionExtranjero,          // B409 - Número identificación  
    'dPaisExt' => $this->paisExtranjero,                        // B410 - País extranjero
    'dProvExt' => $this->codigoProvinciaExtranjero,             // B411 - Provincia (opcional)
    'dDistrExt' => $this->codigoDistritoExtranjero,             // B412 - Distrito (opcional)
    'dCorregExt' => $this->codigoCorregimientoExtranjero,       // B413 - Corregimiento (opcional)
    'dUrbanExt' => $this->urbanizacionExtranjero,               // B414 - Urbanización (opcional)
    'dDirExt' => $this->direccionExtranjero,                    // B415 - Dirección (opcional)
    'dTfnExt' => $this->telefonoExtranjero,                     // B416 - Teléfono (opcional)
],

🔄 Mapeo Actual vs Correcto

ANTES (Implementación Incompleta)

  • receptor_pasaporteIdentidadExtranjeradIdExt (campo incorrecto)
  • receptor_paisNacionalidaddPaisExt (concepto incorrecto)
  • Faltan 7 campos de B406-B416

DESPUÉS (Implementación Correcta)

  • tipoIdentificacionExtranjerocTipoId (B408)
  • numeroIdentificacionExtranjerodIdExt (B409)
  • paisExtranjerodPaisExt (B410)
  • codigoProvinciaExtranjerodProvExt (B411)
  • codigoDistritoExtranjerodDistrExt (B412)
  • codigoCorregimientoExtranjerodCorregExt (B413)
  • urbanizacionExtranjerodUrbanExt (B414)
  • direccionExtranjerodDirExt (B415)
  • telefonoExtranjerodTfnExt (B416)

🤔 Campos Duplicados que Necesitan Unificación

1. País del Receptor

Conflicto: - receptor_paisDestinoOperacioncPaisRec (país destino de operación) - paisExtranjerodPaisExt (país del extranjero en gIdExt)

¿Son el mismo concepto? - cPaisRec: País donde se realiza la operación comercial - dPaisExt: País de origen/nacionalidad del extranjero

Conclusión: SON DIFERENTES - pueden ser distintos (ej: cliente chileno comprando en Panamá)

2. Identificación del Extranjero

Conflicto: - receptor_pasaporteIdentidadExtranjera (campo actual) - numeroIdentificacionExtranjero (B409 correcto)

Conclusión: UNIFICAR - numeroIdentificacionExtranjero es más genérico y correcto

🔧 Plan de Unificación

Paso 1: Mantener Campos Existentes por Compatibilidad

// Mantener estos campos para no romper funcionalidad existente
public $receptor_pasaporteIdentidadExtranjera = null; // DEPRECATED pero funcional
public $receptor_paisDestinoOperacion = null;         // MANTENER - concepto diferente

Paso 2: Usar Campos B406-B416 como Principales

// Casos de uso:
// Si usuario llena campos nuevos (B406-B416) → usar esos
// Si usuario llena campos viejos → mapear automáticamente a nuevos
// Priorizar campos nuevos sobre viejos

Paso 3: Validaciones Unificadas

// Validación: O campos viejos O campos nuevos, pero no ambos vacíos
'numeroIdentificacionExtranjero|receptor_pasaporteIdentidadExtranjera' => 'required_without_all'

Paso 4: Mapeo Final Unificado

// En la estructura final, usar SIEMPRE los campos B406-B416
$numeroId = $this->numeroIdentificacionExtranjero ?: $this->receptor_pasaporteIdentidadExtranjera;
$paisExt = $this->paisExtranjero ?: $receptorPaisNacionalidad?->code;

'gIdExt' => [
    'cTipoId' => $this->tipoIdentificacionExtranjero ?: '99', // Default: Otro
    'dIdExt' => $numeroId,
    'dPaisExt' => $paisExt,
    // ... resto de campos opcionales
]

🎯 Recomendación

UNIFICAR MANTENIENDO COMPATIBILIDAD:

  1. Mantener campos existentes para no romper funcionalidad
  2. Implementar campos B406-B416 completos como principales
  3. Mapeo automático de campos viejos a nuevos cuando sea necesario
  4. Priorizar campos nuevos en la estructura final
  5. Validaciones flexibles que permitan ambos enfoques

Esto asegura: - ✅ Cumplimiento total con DGI (B406-B416) - ✅ Compatibilidad hacia atrás (campos existentes funcionan)
- ✅ Migración gradual (usuarios pueden adoptar nuevos campos) - ✅ Estructura correcta en facturación electrónica


Next Step: Implementar la unificación en Create.php líneas ~1660-1670