Estándares de Archivos de terceros para importación ETL (Extract, Transform, Load) o ELT (Extract, Load, Transform) en Novohit

Estándares de Archivos de terceros para importación ETL (Extract, Transform, Load) o ELT (Extract, Load, Transform) en Novohit

Para aquellos casos en los que no existen Interfaces API ya existentes, en el ERP de Novohit se pueden importar archivos externos para ser procesados en la plataforma y automatizar ciertas tareas transaccionales de ciertos módulos típicamente en procesos ETL/ELT, procesamiento de transacciones financieras, facturación masiva, nómina, pagos, cuentas por pagar, etc.
​
En los casos en los que la lógica de negocios lo justifique y no exista la funcionalidad previamente en Novohit será necesario realizar un desarrollo o parametrización a un desarrollo existente basado en la estructura del archivo a importar para que pueda ser procesado con éxito.
​
Para que el archivo pueda ser importado y procesado de manera transaccional en modo batch confiable sin depender de modelos de lenguaje interpretativos ni IA generativa (lo cual introduciría potenciales inconsitencias), debe cumplir con un conjunto de características muy estrictas. Estas minimizan los errores, permiten validaciones automáticas fuertes y hacen viable el procesamiento atómico, idempotente y reparable.
​
A continuación las principales características esperadas:

#CaracterísticaPor qué es críticaEjemplo de buen diseño vs. mal diseño
0
 Documentado
Para que se pueda realizar un desarrollo consistente basado en documentación oficial versionada por parte del proveedor o emisor del archivo, con cada campo descrito en lenguaje natural y los tipos de datos definidos. 
Bueno: documentación oficial del archivo campo por campo / Malo: sin documentación o documentación incompleta.
1Estructura fija y consistenteEl parser debe saber exactamente dónde está cada campo sin ambigüedadBueno: CSV con 18 columnas siempre / Malo: JSON variable
2Esquema rígido / schema-on-read estrictoPermite validación automática inmediata (tipos, obligatoriedad, longitud)Columnas con tipos fijos + NOT NULL claros
3Delimitadores y codificación claros y uniformesEvita errores de parsing catastróficos; o + UTF-8 sin BOM / Malo: mezcla tab, coma, utf-16
4Encabezado presente y obligatorioFacilita validación automática y autodescubrimiento de columnasPrimera fila = nombres de columnas exactos
5Valores atómicos (1NF)Evita tener que parsear dentro del campo durante la carga“2025-02-20” en vez de “20/02/2025 14hs”
6Normalización de formatosElimina variaciones que rompen reglas de negocioFechas → ISO 8601, montos → decimal con punto, sin símbolo $
7Códigos control / lookup cerradosPermite validación contra tablas maestras“tipo_doc”: solo “C”, “P”, “DNI”, “CI”, “RUC”
8Clave única / negocio claraPermite detección de duplicados y procesamiento idempotenteCampo o combinación = “ID_TRANSACCION” o “FOLIO+FECHA+MONTO”
9Mecanismo de trazabilidadNecesario para auditoría y re-procesosCampo “source_file_name”, “line_number”, “batch_id”
10Tamaño y volumen predecibleEvita problemas de memoria y timeouts en el importadorArchivos < 2-5 GB, < 1-5M registros por archivo
11Ausencia (o muy controlada) de nulosLos nulos mal gestionados rompen muchas reglas de integridadUsar valores centinela claros (-1, ‘9999-12-31’, etc.)
12Separación clara entre header y detailMuy común en interfaces financieras y facturaciónTipo registro = ‘H’ / ‘D’ / ‘T’ (trailer)
13Control de integridad simplePermite validación rápida antes de procesarCantidad registros en trailer, sumatoria de montos
14Formato preferido(en 2025-2026) los más robustos para procesamiento transaccional

CSV → Fixed-width → Parquet columnar (si ya es stage)

Jerarquía práctica de “calidad” para procesamiento transaccional

Nivel A (ideal)

CSV o Campos Fijos con:
  1. UTF-8 sin BOM
  2. Delimitador no presente en datos (o escapado correctamente)
  3. Encabezado obligatorio
  4. Todos los campos con formato estricto + validadores (regex o longitud fija)
  5. Trailer con control de registros y sumatorias
  6. Clave candidata única declarada

Nivel B (aceptable)

  1. CSV sin encabezado (pero con documentación clara y rígida)
  2. JSON Lines (cada línea un registro independiente)
  3. Parquet / Avro con schema embebido

Nivel C (no aceptable)

Notes
En estos casos es posible que se rechaze el desarrollo y se favorecerá la integración con una API
  1. JSON anidado profundo
  2. Excel con múltiples hojas y formato libre
  3. Archivos con estructura variable (campos condicionales)

Nivel D (no aceptable para ETL/ELT; solo para ser anexados)

Warning
Si bien estos tipos de archivos se pueden importar (como ya se hace en varios módulos), solo pueden ser anexardos a transacciones existentes. No se realizarán desarrollos ETL/ELT transaccionales sobre estos tipos de archivos.
  1. PDF, imágenes, Word, emails
  2. Archivos con encoding mixto
  3. Datos sin delimitador claro ni estructura repetible
Alert
Los criterios generales aquí descritos son técnicos. Nuestro staff se resrva el derecho para aplicar criterios técnicos, administrativos y comerciales de acuerdo a nuestras Políticas para Solicitudes de Mejoras, Nuevas Funcionalidades, Integraciones API, nuestros Términos de Servicio de Soporte Backups, Actualizaciones y Monitoreo Novohit SBAM y nuestros Terminos Comerciales Universales Novohit