Saltar al contenido principal

Overview técnico

:::info Flujo de referencia La integración Opera se compone de recepción JSON, transformación fiscal, envío tributario y respuesta estructurada al ERP. :::

1. Flujo Operativo​

1.1 Recepción de Transacción​

  • Protocolo: HTTPS
  • Método: POST
  • Formato: JSON
  • Autenticación: Basic Auth

Oracle Opera - Hospitality Cloud envía la información completa de la transacción de facturación hacia nuestra API-FLIP (payload JSON).

1.2 Transformación Estructural​

API-FLIP:

  1. Valida estructura JSON.
  2. Convierte JSON → XML intermedio (DTE - GUF).
  3. Aplica transformación mediante archivo XSLT.
  4. Genera el DTE-GUF con la estructura fiscal requerida por el país.

La transformación permite:

  • Adaptabilidad multi-país.
  • Independencia del formato ERP.
  • Versionamiento controlado por regulación.

1.3 Envío al Ente Tributario​

  • API-FLIP invoca al API de emisión convencional (SendDocumentToAuthority).
  • Se realiza:
    • Firma digital (si aplica).
    • Validación final.
    • Envío al ente tributario.
  • Se obtiene respuesta de:
    • Autorización
    • Rechazo
    • Observación

1.4 Asignación de Folio​

Una vez generado el DTE y enviado al API SendDocumentToAuthority:

  • API invoca un servicio interno de folios (Gestor de folios).
  • Se valida disponibilidad.
  • Se asigna folio único fiscal.
  • Se actualiza el DTE con el folio correspondiente.

Este paso garantiza correlatividad y control tributario.

1.5 Respuesta al ERP​

API-FLIP construye una respuesta en formato JSON que incluye:

  • Estado de la operación (AUTHORIZED / ERROR)
  • Código tributario
  • Mensaje descriptivo de aceptación u observaciones encontradas, dependiendo del ente fiscal.
  • Folio asignado
  • Identificador fiscal (UUID / CAE / TrackID según país)
  • Fecha de autorización

Ejemplo conceptual:

{
  "status": "AUTHORIZED",
  "folio": "12345",
  "authorizationDate": "2026-02-13",
  "fiscalId": "ABC-123456",
  "message": "Documento autorizado correctamente"
}

2. Seguridad​

  • Comunicación HTTPS (TLS 1.2+)
  • Autenticación Basic Auth
  • Logs auditables
  • Control de correlatividad de folios
  • Separación de responsabilidades por servicios internos

3. Consideraciones Técnicas Relevantes​

  • Arquitectura orientada a servicios.
  • Transformación basada en XSLT versionable.
  • Servicios internos desacoplados.
  • Flujo síncrono hacia ERP (Dependiendo de la localidad).
  • Trazabilidad completa por ID de transacción.

4. Endpoints del producto​

:::tip Ambientes Utilizar siempre QA para pruebas funcionales y certificación interna antes de promover configuraciones a PRD. :::

  • QA: https://global-gosocket-api-flip-sbx.azurewebsites.net/api/v1/Document/SendDocumentToAuthority
  • PRD: https://global-gosocket-api-flip.azurewebsites.net/api/v1/Document/SendDocumentToAuthority