🇵🇾 Paraguay

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

Resumen

Aspecto	Valor
Código country	py
Entidad tributaria	SIFEN
Patrón	A — XML con XSD
inputType soportados	json, xml, xdoc, txt
Output	XML tributario firmado
Flujos soportados	Mixto (sync-async) y Asíncrono — ver mas abajo
Cancelaciones	✅ POST /api/v1/cancelation-event (exclusivo de Paraguay)

🔀 Flujos soportados

Paraguay puede operar bajo dos modelos de integración. La diferencia esta en quien dialoga con el SIFEN, 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 SIFEN	xPOS Core	Nube Gosocket
Cuando se conoce el estado oficial	xPOS Core consulta al SIFEN después del envío	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, sección 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: envía 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 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 SIFEN 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 SIFEN (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.
3. xPOS Core → Nube Gosocket: entrega el DTE a la API de Gosocket y recibe un acknowledge de la nube. Texto operativo: "Publica para envío a SIFEN".
4. xPOS Core → POS: responde y sincroniza el Inbox (Emitidos).
5. Nube Gosocket → SIFEN: 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 SIFEN (la nube gestiona reintentos y errores) o cuando la red del POS hacia el SIFEN 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_py.xslt	Entradas json y xml → XML <root> → XML Gosocket.
other_to_dte_py.xslt	Entrada txt → XML Gosocket. No pasa por input_to_dte.
xdoc_to_dte_py.xslt	Entrada xdoc → XML Gosocket. No pasa por input_to_dte.
dte_to_fiscal_py.xslt	XML Gosocket → DTE tributario SIFEN.
custom_response_py.xslt	Genera custom_response cuando aplica.

Tipos de documento (typeDoc)

Ejemplo WebSocket usa typeDoc=1.

Campos del response específicos 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 (Código de Control SIFEN, 44 dígitos).
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 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	–	Paraguay 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 SIFEN — ese estado se consulta después (ver Flujos soportados).

{
"env": "sbx",
"operation": "consolidate",
"typeDoc": 1,
"country": "py",
"inputType": "json",
"origin": "<taxId del emisor>",
"document": { /* DTE Paraguay */ }
}

Notas particulares

• Reobtención de estado:
  • En modelo mixto, usar GET /api/v1/status con transactionId o docNumber + 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.
• Cancelaciones: Paraguay es el único país que dispara POST /api/v1/cancelation-event desde el POS. Aplica en ambos modelos. Ver Protocolo · Cancelaciones.