La integración regional no consiste en copiar campos. Omie, SIGE Cloud, Zoho Creator, hojas y bases SQL representan clientes, productos, servicios, pedidos, facturas, pagos y workflows de formas distintas. La arquitectura debe conservar esas diferencias y ofrecer un modelo operativo estable.
Define qué sistema controla cada hecho. El ERP puede ser dueño de productos fiscales, facturas, cuentas por cobrar y stock. Zoho Creator puede controlar workflow de servicios, aprobaciones o formularios. CRM controla interacción comercial. SQL preserva evidencia e historia. Sheets presenta un reporte para personas.
Dos sistemas pueden guardar el nombre del cliente, pero solo uno controla el registro legal. Sin ownership por campo, el sync bidireccional se convierte en un loop de sobrescritura.
Omie organiza operaciones por servicios de negocio; SIGE Cloud expone recursos ERP; Zoho Creator trabaja con forms, reports, field link names, validación, workflows, paginación y bulk jobs. No son CRUDs equivalentes.
Cada adapter conoce auth, páginas, cuotas, filtros, estados, producto versus servicio, errores, retries y mutations. El pipeline central consume un contrato normalizado.
Guarda payload original con provider, tenant, recurso, external ID, extracción, source update time, versión API, ventana, hash y run. Esto permite reproducir transformaciones e investigar drift.
La normalización crea tablas o eventos separados. Los campos desconocidos no desaparecen; van a quarantine o compatibilidad explícita.
No asumas que identificador fiscal, email, SKU o nombre es único global. Guarda tenant, source, resource, external ID, canonical ID, validez, método, confianza e historia de merge/split. Conserva aliases.
Usa claves deterministas cuando exista garantía y matching limitado con revisión en los demás casos.
Usa updated_at o cursor con ventana superpuesta. Registra rango, páginas, timestamps, vistos, únicos, rechazados y watermark committed.
Separa sync reciente y backfill. No avances watermark si falta una página.
Repetir lectura suele ser inocuo; repetir creación, facturación, cancelación, stock o pago causa daño. Cada mutation requiere operation ID, versión, precondiciones, lookup, hash, result ledger y retry class.
Busca por integration key antes de crear. Tras timeout consulta estado. Separa transporte/rate limit de validación, permiso, fiscal y negocio. Conserva la causa específica.
Un servicio no es un producto sin stock. Puede usar impuestos, documentos, códigos y ciclos diferentes. Comparte campos comunes sin borrar el tipo fiscal.
Usa decimal, moneda, base, descuento, flete y redondeo explícitos. Conserva códigos y documentos del ERP.
Sheets es útil para equipos, pero no es event store ni base transaccional. Publica snapshot versionado o ranges con ownership claro. Protege fórmulas, headers y row keys.
Respeta cuotas con batch y backoff. Prefiere actualización atómica a cambios fila por fila. Incluye run marker, ventana, tiempo, filas, schema y estado.
PostgreSQL guarda raw metadata, identity maps, proyecciones, ledgers, watermarks, conciliación y excepciones. Unique constraints aplican idempotencia; FKs y checks protegen relaciones y estados; transacciones agrupan cambios.
Raw responde qué llegó; canónico qué significa; views responden la pregunta actual.
| Dominio | Owner típico | Lectura | Escritura | Evidencia |
|---|---|---|---|---|
| Cliente/proveedor legal | ERP o master data. | Incremental con overlap y revisión de duplicados. | Upsert por integration key con validación fiscal. | ID map, documento, estado, dirección y actualización. |
| Workflow custom | Zoho Creator o app. | Reports, paginación, ventana o bulk. | Update sujeto a validación/workflows. | Record ID, form/report, workflow, historia y error. |
| Catálogo | ERP. | Referencia completa más cambios. | Paths separados producto/servicio. | SKU, tipo fiscal, activo, precio y stock. |
| Pedidos/documentos | ERP en fiscal; app puede controlar intención. | Ventanas recientes, refresh y webhook. | Crear una vez y transicionar con versión. | IDs, líneas, totales, número fiscal, cancelación y pago. |
| Snapshot de reporte | Modelo SQL; Sheets presenta. | View/export versionado. | Batch replacement o append acotado. | Run, schema, filas, totales, tiempo y watermark. |
| Control de integración | SQL/control plane. | Jobs, mappings, policies y resultados. | Attempts append-only y proyecciones transaccionales. | Trace, request/response, idempotencia, retry y owner. |
Webhook ofrece baja latencia pero debe disparar fetch o verificación. Polling cubre backfill, eventos perdidos y recursos sin webhook. Ambos entran al mismo pipeline deduplicado.
Monitorea edad, autenticación, event ID, versión y resultado. La falla activa polling fallback.
Normaliza timeout, rate limit, auth, permiso, not found, validación, duplicate, rechazo fiscal, workflow, conflict e interno. Conserva código y mensaje saneado junto con entidad, operación, payload, intento, policy y owner.
Un mensaje genérico pierde la acción correctiva ya informada por el ERP.
Compara totales de pedidos, facturas, receivables, pagos, stock, clientes activos, etapas y freshness. Detecta solo-source, solo-target y versiones conflictivas.
La excepción necesita owner, severidad, impacto, edad, evidencia, acción y cierre. No hagas overwrite automático sobre discrepancias fiscales o financieras.
Guarda keys, secrets, refresh tokens, SQL y service accounts en secret manager o CI protegida. Scope por tenant y capacidad. No registres secretos ni payloads sensibles completos.
Tenant context debe existir en tablas, colas, cache y traces. Autoriza en la frontera de write.
Usa fixtures para páginas vacías, null, decimal, timezone, enum nuevo, validación, rate limit, partial success, timeout post-commit, webhook duplicado y drift. Usa sandbox o cuenta controlada.
Backfill y replay deben ser idempotentes; evento antiguo no sobrescribe versión reciente.
Mide requested, received, normalized, inserted, updated, unchanged, rejected, retried y reconciled. Acompaña cuota, watermark lag, excepción más antigua, tiempo de Sheets y freshness.
Correlaciona run, request, raw, entidad, operación, resultado, snapshot y caso. Worker verde no prueba datos actuales.
Construiría una plataforma con adapters, scheduler durable, landing raw, schemas canónicos, identity mapping, operation ledger, proyecciones SQL, conciliación, consola de excepciones y publishers. Reads y writes usarían credenciales y colas separadas.
Cada package declararía recursos, páginas, incremental key, límites, webhooks, idempotencia, fiscal, errores y fixtures.
Una integración regional exitosa no finge que todos los sistemas son iguales. Explicita diferencias, conserva verdad de origen, traduce significado con contratos y prueba el outcome de cada sync.
Artículo sobre integración ERP en América Latina entre Omie, SIGE Cloud, Zoho Creator, Google Sheets y SQL, incluyendo ownership, ingesta raw, modelos canónicos, identity mapping, sync incremental, mutations idempotentes, fiscal, conciliación, errores, seguridad, pruebas y observabilidad.