🇨🇱 Chile

Esta ficha asume que conoces el protocolo de comunicación xPOS-Core. Aquí solo documentamos lo especifico de Chile.

Resumen

Aspecto	Valor
Código country	cl
Entidad tributaria	SII
Patrón	A — XML con XSD
inputType soportados	json, xml, xdoc, txt
Output	XML tributario (DTE) firmado con TED
Flujos soportados	Mixto (sync-async) y Asíncrono — ver mas abajo

🔀 Flujos soportados

Chile puede operar bajo dos modelos de integración. La diferencia esta en quien dialoga con el SII, y se elige en la configuración del xPOS. De cara al POS, el protocolo de invocación es el mismo en ambos modelos (mismo endpoint, mismos parámetros, misma estructura de response); lo que cambia es el comportamiento interno y como se obtiene el estado oficial.

Para entender la coreografia completa con diagramas, ver Arquitectura global xPOS.

Tabla comparativa

Aspecto	Modelo mixto (sync-async)	Modelo asíncrono
Quien envía al SII	xPOS Core	Nube Gosocket
Cuando se conoce el estado oficial	xPOS Core consulta al SII después del envío	Lo gestiona la nube Gosocket
Reintentos contra el SII	Los hace xPOS Core	Los hace la nube Gosocket
Campos eco (statusCode, statusDescription, statusMessage) en el response inicial	Vacios en el primer response. Se completan cuando xPOS Core consulta el estado.	xPOS Core no los devuelve (no dialoga con el SII).
/api/v1/status	Devuelve el estado fiscal actualizado tras la consulta de xPOS al SII.	xPOS Core no puede entregar el estado fiscal final. Se consulta directamente en el portal Inbox de Gosocket, sección Emitidos.

Modelo mixto (sync-async)

Flujo paso a paso:

1. POS → xPOS Core: envía el documento (POST /api/v1/process-documents).
2. xPOS Core: valida XSD/Schematron, asigna folio y firma con TED.
3. xPOS Core → SII: entrega el DTE y recibe un acknowledge de recepción. El DTE queda en el Inbox sin estado fiscal.
4. xPOS Core → POS: responde confirmando que el documento fue aceptado para procesar.
5. Mas tarde: xPOS Core consulta el estado al SII y actualiza el DTE en el Inbox (Emitidos).
6. POS → xPOS Core: recupera el estado oficial vía GET /api/v1/status.

Cuando elegirlo

Cuando el cliente quiere que xPOS controle directamente la comunicación con el SII (lógica de reintentos, auditoria local) y dispone de conectividad estable hacia el ente tributario.

Modelo asíncrono

Flujo paso a paso:

1. POS → xPOS Core: envía el documento (POST /api/v1/process-documents).
2. xPOS Core: valida XSD/Schematron, asigna folio y firma con TED.
3. xPOS Core → Nube Gosocket: entrega el DTE a la API de Gosocket y recibe un acknowledge de la nube.
4. xPOS Core → POS: responde y sincroniza el Inbox (Emitidos).
5. Nube Gosocket → SII: la nube envía el DTE de forma asíncrona, gestiona reintentos y concilia el estado oficial.

Cuando elegirlo

Cuando el cliente prefiere desentenderse de la conectividad con el SII (la nube gestiona reintentos y errores) o cuando la red del POS hacia el SII es inestable.

Como se configura el modelo

La selección entre modelo mixto y modelo asíncrono se define en el portal de administración de Gosocket durante la etapa de implementación del cliente. El xPOS Core recibe ese flag a través de los datos de onboarding: no es un parámetro que viaje en cada llamada a /api/v1/process-documents.

Mapeo de XSLT

XSLT	Uso
input_to_dte_cl.xslt	Entradas json y xml → XML <root> → XML Gosocket.
other_to_dte_cl.xslt	Entrada txt → XML Gosocket. No pasa por input_to_dte.
xdoc_to_dte_cl.xslt	Entrada xdoc → XML Gosocket. No pasa por input_to_dte.
dte_to_fiscal_cl.xslt	XML Gosocket → DTE tributario SII.
custom_response_cl.xslt	Genera custom_response cuando aplica.

Tipos de documento (typeDoc)

Ejemplo WebSocket usa typeDoc=39 (boleta electrónica).

typeDoc	Documento
33	Factura electrónica
34	Factura exenta electrónica
39	Boleta electrónica
41	Boleta exenta electrónica
52	Guia de despacho electrónica
56	Nota de débito electrónica
61	Nota de crédito electrónica

Campos del response específicos de Chile

Chile devuelve un subset reducido del nucleo: el SII responde de forma diferida en ambos modelos, por lo que el response inicial nunca trae los campos eco. Lo único distintivo de Chile es el formato del código visual.

Campo	Estado	Notas
barcodeBase64	✓	PDF417 en base64 (no QR — Chile usa PDF417 para el TED).
barcodeText	–	Chile no devuelve la representación en texto del PDF417.
countryIdentificationCode	–	No se devuelve.
statusCode / statusDescription / statusMessage	–	No vienen en el response inicial. En modelo mixto se completan con GET /api/v1/status tras la consulta de xPOS al SII. En modelo asíncrono xPOS Core no los devuelve nunca: el estado fiscal final se consulta en el portal Inbox de Gosocket (sección Emitidos).
applicationResponse, timeGeneration, timeValidation	–	Idem (asíncrono en ambos modelos).
contingencyCode	–	Chile no usa contingencyCode en el response de xPOS Core.

Ejemplo WebSocket

Valores ilustrativos. La estructura es real; los datos son ejemplos. Esta es la respuesta inicial de xPOS Core; aplica a los dos flujos (mixto y asíncrono) y no trae eco del SII — ese estado se consulta después (ver Flujos soportados).

{
"env": "sbx",
"operation": "consolidate",
"typeDoc": 39,
"country": "cl",
"inputType": "json",
"origin": "<taxId del emisor>",
"document": { /* boleta electronica */ }
}

Notas particulares

• TED firmado: el response trae el TED (Timbre Electrónico de Documentos) firmado embebido en el output.
• Reobtención de estado:
  • En modelo mixto, usar GET /api/v1/status con transactionId o folio + typeDoc para obtener el estado fiscal actualizado.
  • En modelo asíncrono, xPOS Core no puede entregar el estado fiscal final. La consulta se hace en el portal Inbox de Gosocket, sección Emitidos.