🇵🇾 Paraguay

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

Resumen

Aspecto	Valor
Codigo country	py
Entidad tributaria	SIFEN
Patron	A — XML con XSD
inputType soportados	json, xml (no soporta txt)
Output	XML tributario firmado
Flujos soportados	Mixto (sync-async) y Asincrono — ver mas abajo
Cancelaciones	✅ POST /api/v1/cancelation-event (exclusivo de Paraguay)

🔀 Flujos soportados

Paraguay puede operar bajo dos modelos de integracion. La diferencia esta en quien dialoga con el SIFEN, 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 SIFEN	xPOS Core	Nube Gosocket
Cuando se conoce el estado oficial	xPOS Core consulta al SIFEN despues del envio	Lo gestiona la nube Gosocket
Reintentos contra el SIFEN	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 SIFEN).
/api/v1/status	Devuelve el estado fiscal actualizado tras la consulta de xPOS al SIFEN.	xPOS Core no puede entregar el estado fiscal final. Se consulta directamente en el portal Inbox de Gosocket, seccion Emitidos.
Cancelaciones	POST /api/v1/cancelation-event aplica en ambos modelos.	POST /api/v1/cancelation-event aplica en ambos modelos.

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.
3. xPOS Core → SIFEN: 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 SIFEN 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 SIFEN (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.
3. xPOS Core → Nube Gosocket: entrega el DTE a la API de Gosocket y recibe un acknowledge de la nube. Texto operativo: "Publica para envio a SIFEN".
4. xPOS Core → POS: responde y sincroniza el Inbox (Emitidos).
5. Nube Gosocket → SIFEN: 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 SIFEN (la nube gestiona reintentos y errores) o cuando la red del POS hacia el SIFEN 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_py.xslt	JSON → XML <root> → XML Gosocket.
dte_to_fiscal_py.xslt	XML Gosocket → DTE tributario SIFEN.
custom_response_py.xslt	Genera custom_response cuando aplica.

Tipos de documento (typeDoc)

TODO: completar con producto. Ejemplo Socket usa typeDoc=1.

Campos del response especificos de Paraguay

Paraguay devuelve un subset reducido del nucleo: el SIFEN responde de forma diferida en ambos modelos, por lo que el response inicial no trae eco de la entidad.

Campo	Estado	Notas
barcodeText / barcodeBase64	✓	QR del CDC.
countryIdentificationCode	✓	CDC (Codigo de Control SIFEN, 44 digitos). TODO confirmar.
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 SIFEN. 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	–	Paraguay 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 SIFEN — ese estado se consulta despues (ver Flujos soportados).

{
"env": "sbx",
"operation": "consolidate",
"typeDoc": 1,
"country": "py",
"inputType": "json",
"document": { /* DTE Paraguay */ }
}

Notas particulares

• No soporta inputType=txt (unicos formatos: json y xml).
• Reobtencion de estado:
  • En modelo mixto, usar GET /api/v1/status con transactionId o docNumber + 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.
• Cancelaciones: Paraguay es el unico pais que dispara POST /api/v1/cancelation-event desde el POS. Aplica en ambos modelos. Ver Protocolo · Cancelaciones.