🇨🇱 Chile

Esta ficha asume que conoces el protocolo de comunicacion xPOS-Core. Aqui solo documentamos lo especifico de Chile.

Resumen

Aspecto	Valor
Codigo country	cl
Entidad tributaria	SII
Patron	A — XML con XSD
inputType soportados	json, xml, txt
Output	XML tributario (DTE) firmado con TED
Flujos soportados	Mixto (sync-async) y Asincrono — ver mas abajo

🔀 Flujos soportados

Chile puede operar bajo dos modelos de integracion. La diferencia esta en quien dialoga con el SII, y se elige en la configuracion del xPOS. De cara al POS, el protocolo de invocacion es el mismo en ambos modelos (mismo endpoint, mismos parametros, 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 asincrono
Quien envia al SII	xPOS Core	Nube Gosocket
Cuando se conoce el estado oficial	xPOS Core consulta al SII despues del envio	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, seccion Emitidos.

Modelo mixto (sync-async)

Flujo paso a paso:

1. POS → xPOS Core: envia 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 recepcion. 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 via GET /api/v1/status.

Cuando elegirlo

Cuando el cliente quiere que xPOS controle directamente la comunicacion con el SII (logica de reintentos, auditoria local) y dispone de conectividad estable hacia el ente tributario.

Modelo asincrono

Flujo paso a paso:

1. POS → xPOS Core: envia 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 envia el DTE de forma asincrona, 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 seleccion entre modelo mixto y modelo asincrono se define en el portal de administracion de Gosocket durante la etapa de implementacion del cliente. El xPOS Core recibe ese flag a traves de los datos de onboarding: no es un parametro que viaje en cada llamada a /api/v1/process-documents.

Mapeo de XSLT

XSLT	Uso
input_to_dte_cl.xslt	JSON/TXT → XML <root> → XML Gosocket.
dte_to_fiscal_cl.xslt	XML Gosocket → DTE tributario SII.
custom_response_cl.xslt	Genera custom_response cuando aplica.

Tipos de documento (typeDoc)

TODO: completar con producto. Ejemplo Socket usa typeDoc=39 (boleta electronica).

typeDoc	Documento
33	Factura electronica
34	Factura exenta electronica
39	Boleta electronica
41	Boleta exenta electronica
52	Guia de despacho electronica
56	Nota de debito electronica
61	Nota de credito electronica

Campos del response especificos 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 unico distintivo de Chile es el formato del codigo visual.

Campo	Estado	Notas
barcodeBase64	✓	PDF417 en base64 (no QR — Chile usa PDF417 para el TED).
barcodeText	–	Chile no devuelve la representacion 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 asincrono xPOS Core no los devuelve nunca: el estado fiscal final se consulta en el portal Inbox de Gosocket (seccion Emitidos).
applicationResponse, timeGeneration, timeValidation	–	Idem (asincrono en ambos modelos).
contingencyCode	–	Chile no usa contingencyCode en el response de xPOS Core.

Ejemplo Socket

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 asincrono) y no trae eco del SII — ese estado se consulta despues (ver Flujos soportados).

{
"env": "sbx",
"operation": "consolidate",
"typeDoc": 39,
"country": "cl",
"inputType": "json",
"document": { /* boleta electronica */ }
}

Notas particulares

• TED firmado: el response trae el TED (Timbre Electronico de Documentos) firmado embebido en el output.
• Reobtencion de estado:
  • En modelo mixto, usar GET /api/v1/status con transactionId o folio + typeDoc para obtener el estado fiscal actualizado.
  • En modelo asincrono, xPOS Core no puede entregar el estado fiscal final. La consulta se hace en el portal Inbox de Gosocket, seccion Emitidos.