🇵🇪 Perú

Esta ficha asume que conoces el protocolo de comunicación xPOS-Core. Aquí solo documentamos lo específico de Perú.

País nuevo en la versión 2.7.0

Perú se suma a la familia xPOS en xPOS-Core 2.7.0, con los mismos principios de la plataforma: la venta nunca se detiene, y la operación con varios emisores en un mismo equipo está disponible desde el primer día.

Respuesta y contingencia renovadas en la versión 2.7.1

Desde xPOS-Core 2.7.1, el código HTTP de la respuesta le indica al POS qué hacer, solo se encola lo que no llegó a la entidad tributaria, xPOS recupera el documento cuando el POS reenvía el mismo número, las facturas en contingencia se reenvían solas y la respuesta trae el QR de SUNAT.

Resumen

Aspecto	Valor
Código `country`	`pe`
Entidad tributaria	SUNAT, directo o a través del OSE Gosocket
Patrón	A — XML con XSD
Canal	Solo REST (`POST /api/v1/process-documents`). No hay integración por WebSocket
`inputType` soportados	`json`, `xml`, `txt`, `xdoc`
Numeración	La serie y el correlativo los pone el POS: xPOS no asigna folio
Output	XML tributario (UBL 2.1) firmado, con el QR de SUNAT
Contingencia	Solo lo que no llegó a la entidad tributaria: boletas al Resumen Diario, facturas al reenvío automático

Lo propio de Perú: qué responde xPOS al POS según el código HTTP, el reenvío del mismo número, la contingencia con sus plazos, el Resumen Diario, el comprobante físico regularizado y el QR de la representación impresa.

Perú sigue el flujo síncrono de xPOS: el veredicto de la entidad tributaria llega en la misma llamada, y el POS recibe 200 entregar, 503 reintentar ya, 510 corregir y reintentar o 400 no se emitió. Detalle en Qué responde xPOS al POS.

🔀 Destino por tipo de documento: SUNAT u OSE

Perú admite dos destinos para el mismo documento: SUNAT directo o el OSE (Operador de Servicios Electrónicos) Gosocket. Los dos devuelven la Constancia de Recepción (CDR) en la misma llamada: cambian el destino y las credenciales, no el contrato con el POS.

Cómo se configura el destino

El destino se define en el portal de administración de Gosocket, en la configuración del emisor, por tipo de documento: cada typeDoc se rutea a SUNAT o al OSE, y el Resumen Diario tiene su propia regla. Sin regla definida para un tipo, el destino es SUNAT. xPOS recibe estas reglas de ruteo (routingRules) con los datos de onboarding: no es un parámetro que viaje en cada llamada.

Tipos de documento (`typeDoc`)

`typeDoc`	Documento	Esquema de validación
`01`	Factura Electrónica	`UBL-Invoice-2.1.xsd`
`03`	Boleta de Venta Electrónica	`UBL-Invoice-2.1.xsd`
`05`	Boleto de Transporte Aéreo	`UBL-Invoice-2.1.xsd`
`07`	Nota de Crédito Electrónica	`UBL-CreditNote-2.1.xsd`
`08`	Nota de Débito Electrónica	`UBL-DebitNote-2.1.xsd`
`09`	Guía de Remisión Remitente	`UBL-DespatchAdvice-2.1.xsd`
`14`	Servicios Públicos Electrónicos	`UBL-Invoice-2.1.xsd`
`25`	Documento de atribución	`UBL-Invoice-2.1.xsd`
`30`	DAE Adquiriente	`UBL-Invoice-2.1.xsd`
`31`	Guía de Remisión Transportista	`UBL-DespatchAdvice-2.1.xsd`
`34`	DAE Operador	`UBL-Invoice-2.1.xsd`
`42`	DAE Adquiriente	`UBL-Invoice-2.1.xsd`
`56`	Comprobante de pago SEAE / DAE-SEAE	`UBL-Invoice-2.1.xsd`

Todos los tipos comparten el mismo camino de transformación; lo que cambia según el tipo es el esquema UBL de validación y el servicio de SUNAT al que se envía (las guías 09 y 31 van al servicio de Guía de Remisión).

Comunicación de Baja y Resumen Diario son internos

Los eventos RA (Comunicación de Baja) y RC (Resumen Diario) no se emiten desde el POS: los construye y envía el propio xPOS. El Resumen Diario se documenta más abajo.

Formatos de entrada (`inputType`)

`inputType`	Soportado	Detalle
`json`	✓	El GUF del comprobante. Camino completo de transformación (root → DTE genérico → UBL fiscal).
`xml`	✓	El POS envía el DTE genérico de xPOS, no el UBL de SUNAT: se omiten las primeras transformaciones y solo corre la conversión a UBL fiscal.
`txt`	✓	Texto plano del POS, con su hoja de transformación propia. Ver Dónde entran `txt` y `xdoc`.
`xdoc`	✓	xDoc en base64, con su hoja de transformación propia.

Mapeo de XSLT

Las hojas de Perú se distribuyen compiladas (formato .sef — xPOS no compila plantillas en la tienda) y llegan desde el portal con la configuración del emisor:

Hoja	Uso
`input_to_dte_pe.sef`	Entrada `json` → DTE genérico. Con `inputType=xml` este paso se omite.
`dte_to_fiscal_pe.sef`	DTE genérico → UBL fiscal de SUNAT. Corre siempre.
`create_response_pe.sef`	Respuesta Personalizada en `GET /api/v1/status`, cuando el modo de salida del emisor es `Personalizada`.
`summary_documents_pe`	Arma el Resumen Diario a partir de los UBL firmados del día. Va empaquetada en el producto, no en el canal de configuración: cambiar la forma del resumen requiere una actualización de xPOS.

Las entradas txt y xdoc usan sus propias hojas de entrada (other_to_dte y xdoc_to_dte), que llegan por el mismo canal de configuración.

Numeración: la serie y el correlativo viajan en el documento

Perú no folia: la serie y el correlativo los pone el POS en el GUF (<Serie> y <Numero>) y forman la identidad del comprobante, F001-00000001.

El número del comprobante tiene una sola forma, SERIE-CORRELATIVO con guión, en la respuesta (docNumber y countryIdentificationCode), en la consulta GET /api/v1/status y en todas las vistas del dashboard. La respuesta trae además la serie y el correlativo por separado, en series y number.

🚦 Qué responde xPOS al POS

En Perú el código HTTP de la respuesta de POST /api/v1/process-documents ya dice qué hacer. El campo stage y el código de la entidad tributaria (al inicio de error_description) dan el detalle.

200EntregarAceptado por la entidad tributaria (CDR 0), aceptado con observaciones, o en contingencia porque no hubo red. Imprimir con el QR que viene en la respuesta.

503Reintentar ya, mismo númeroNo se sabe si llegó. Reenviar el mismo documento con el mismo número: si la entidad tributaria ya lo tenía, xPOS recupera la constancia.

510Corregir y reintentar, mismo númeroLa entidad tributaria lo recibió y no lo procesó: error interno, credenciales, formato o empaquetado. El número no quedó registrado.

400No se emitióCon ET_RESPONSE_STAGE la entidad tributaria lo rechazó: el número quedó usado, emitir con folio nuevo. Con otra etapa: corregir el documento.

HTTP	Qué pasó	Etapa (`stage`)	Qué hace el POS
200	Aceptado (CDR `0`), aceptado con observaciones, o en contingencia porque no hubo red	—	Entregar e imprimir con el QR de la respuesta
503	No se sabe si llegó: timeout de lectura, corte después de enviar, HTTP 500 sin Fault, 504, Faults `0125`, `0140`, `0307`	`TIMEOUT_ERROR_503`	Reenviar ya el mismo documento con el mismo número
510	La entidad tributaria lo recibió y no lo procesó: error interno (`0109`, `013x`, `020x`, `025x`), credenciales o configuración (`0101`–`0106`, `0110`–`0113`, `0152`–`0154`, `0400`, HTTP 401/403), formato (`1xxx`, `03xx`) o empaquetado (`0151`, `0155`–`0161`, `1034`)	`COMPLIANCE_ERROR_510`	Corregir la causa (o esperar unos minutos si es un error interno de la entidad tributaria) y reenviar con el mismo número: no quedó registrado
400	La entidad tributaria lo rechazó: CDR distinto de `0`, Faults `2xxx`–`3xxx`, `0100`	`ET_RESPONSE_STAGE`	Emitir con folio nuevo: el número quedó usado
400	xPOS no lo pudo procesar: XSD, datos, duplicidad	`VALIDATE_XSD_STAGE`, `INVALID_REQUEST`, `VALIDATE_DUPLICITY_STAGE`, …	Corregir el documento
400	Error inesperado al preparar o enviar, por ejemplo un destino desconocido en las reglas de ruteo del emisor	`SEND_BILL_STAGE`	Revisar la configuración del onboarding; escalar a Gosocket

El status HTTP se deriva del stage

El código HTTP es el status real de la respuesta REST. El stage sigue siendo un campo del cuerpo, distinto del status: el servidor deriva uno del otro (TIMEOUT_ERROR_503 → 503, COMPLIANCE_ERROR_510 → 510, cualquier otro error → 400). La regla es común a todos los países —ver Response y manejo de errores—; Perú la aplica de forma sistemática a toda respuesta de la entidad tributaria.

Perú no está disponible por WebSocket

El canal WebSocket no tiene implementación para Perú. Integra la emisión por REST, con POST /api/v1/process-documents.

El error_description lleva siempre el código de la entidad tributaria adelante:

- No existe información de receptor de documento...
- Usuario o contraseña incorrectos. ...
- El sistema no puede responder su solicitud... Reenvíe el mismo documento en unos minutos.

Dónde queda cada caso

Caso	Documentos procesados	Documentos erróneos	Inbox
Aceptado	Sí	No	Estado 2
Rechazado por la entidad tributaria (400 `ET_RESPONSE_STAGE`)	No	Sí	Estado 3
503 o 510	No	Sí, para diagnóstico	No: el POS va a reintentar el mismo número
En contingencia	Sí, con `contingencyCode`	No	Estado 14

Un 503 o un 510 en «Documentos erróneos» no bloquea el reenvío: la validación de duplicidad solo mira los documentos con respuesta final.

Ejemplos de respuesta

Respuestas de documentos emitidos en sandbox, saneadas: el RUC y el documento del adquirente se reemplazaron por X, y los campos en base64 se muestran cortados.

{
"transactionId": "fe39ba6c-e975-4216-a935-8a7786f85640",
"message": "Operation Successful",
"custom_response": "null",
"errorsDescription": [],
"countryIdentificationCode": "FCON-68",
"timeGeneration": "2026-10-01T13:59:49.486Z",
"output": "PD94bWwgdmVyc2lvbj0iMS4w… (XML firmado, base64)",
"input": "eyJEVEUiOnsiRG9jdW1lbnRv… (GUF recibido, base64)",
"param": "CONSOLIDATE",
"signedXml": "PD94bWwgdmVyc2lvbj0iMS4w… (XML firmado, base64)",
"typeDoc": "01",
"number": "68",
"series": "FCON",
"barcodeText": "20XXXXXXXXX|01|FCON|68|18.00|118.00|2026-10-01|6|20XXXXXXXXX|oJ8T+FnfNL/XDJUYWBWR6PrUYv8=",
"barcodeBase64": "iVBORw0KGgo… (PNG del QR, base64)",
"valorResumen": "oJ8T+FnfNL/XDJUYWBWR6PrUYv8=",
"docNumber": "FCON-68",
"statusCode": "0",
"statusMessage": "El documento FCON-68 ha sido aceptado",
"applicationResponse": "PD94bWwgdmVyc2lvbj0iMS4w… (CDR, base64)"
}

Notas sobre los ejemplos:

output y signedXml son el mismo valor: el UBL firmado en base64, con los Personalizados de vuelta.
En la contingencia no vienen statusCode ni applicationResponse: todavía no hay respuesta de la entidad tributaria. statusMessage trae el motivo: el error de red tal como lo informó el sistema operativo, o «Contingencia manual activa».
En el 503, el POS reenvió el mismo documento con el mismo número un minuto después y salió aceptado: el 503 no gastó el número.
0100 se trata como rechazo (400, emitir con folio nuevo) aunque la entidad tributaria no entregue CDR.

La petición es la misma de todos los países, con country=pe:

POST http://localhost:3200/api/v1/process-documents?env=sbx&operation=consolidate&typeDoc=01&country=pe&inputType=json&origin=20123456789
Content-Type: application/json

{ "DTE": { "Documento": { … } } }

🔁 Reenvío del mismo número y duplicidad

Recuperación al reenviar después de un 503

Después de un 503 el POS reenvía el mismo documento con el mismo número. Si el primer envío sí había llegado, la entidad tributaria contesta 1033/2109 («registrado previamente») o 1032 («ya informado, anulado o rechazado»). En ese caso xPOS busca su intento previo de ese número y consulta la constancia a la entidad tributaria antes de responder:

Constancia	Intento previo en xPOS	Respuesta
Aceptada	Sí	200: se devuelve el XML del primer intento con su CDR
Aceptada	No	400: colisión de numeración, otro comprobante usa ese número; se avisa a Gosocket
Rechazada	—	400 con esa constancia
No existe	—	510: inconsistencia de la entidad tributaria, se escala a Gosocket
La consulta falla	—	503: reintentar en unos minutos
Destino SUNAT directo (sin consulta de constancia)	—	400: verificar en el portal de SUNAT antes de reemitir

La colisión de numeración aparece, por ejemplo, al reutilizar un número ya emitido desde un onboarding anterior del mismo RUC: la entidad tributaria lo tiene registrado y xPOS no tiene un intento previo.

{
"message": "Operation Error",
"error_description": "1033 - Descripción: El comprobante fue registrado previamente con otros datos. La entidad tributaria ya tiene registrado otro comprobante con el número FCON-67 (1033) y xPOS no tiene un intento previo de este folio: colisión de numeración. No se regularizó; emita un folio nuevo y revise la asignación de correlativos.",
"transactionId": "b975be62-dcc7-4c4b-b7a9-6655ea9ebc0e",
"docNumber": "FCON-67",
"stage": "ET_RESPONSE_STAGE",
"applicationResponse": "PHM6RW52ZWxvcGUgeG1sbnM6… (Fault de la ET, base64)",
"input": "eyJEVEUiOnsiRG9jdW1lbnRv… (GUF recibido, base64)",
"output": "PD94bWwgdmVyc2lvbj0iMS4w… (XML firmado, base64)",
"contingencyCode": "null"
}

Duplicidad con la respuesta guardada

Antes de firmar, xPOS revisa si el mismo número del mismo emisor ya tiene una respuesta final. Si la tiene, no lo vuelve a enviar: responde 400 VALIDATE_DUPLICITY_STAGE con lo guardado dentro del error.

Ya aceptado: trae el XML firmado (output) y el CDR (applicationResponse) registrados.
En contingencia: indica que ya está en contingencia, con su contingencyCode.
Rechazado: trae el rechazo guardado y la indicación de emitir con folio nuevo.
Comprobante físico regularizado: se informa como duplicado.

Un 503 o un 510 previo no cuenta como respuesta final, así que el reenvío de ese número pasa normalmente.

{
"message": "Operation Error",
"error_description": "Documento duplicado: el número FCON-68 ya fue aceptado por la entidad tributaria el 2026-10-01T13:59:49.486Z. Se devuelve el XML y la constancia registrados; no se vuelve a enviar.",
"transactionId": "8669979c-722e-4a1d-b87f-48a56cff7dec",
"docNumber": "FCON-68",
"stage": "VALIDATE_DUPLICITY_STAGE",
"applicationResponse": "PD94bWwgdmVyc2lvbj0iMS4w… (CDR guardado, base64)",
"input": "eyJEVEUiOnsiRG9jdW1lbnRv… (GUF recibido, base64)",
"output": "PD94bWwgdmVyc2lvbj0iMS4w… (XML firmado guardado, base64)",
"contingencyCode": "null"
}

🕒 Contingencia

En Perú solo entra a la cola de contingencia lo que nunca llegó a la entidad tributaria. Una respuesta formal de la entidad tributaria en línea —aceptación, rechazo o error— es final y vuelve al POS con su código HTTP.

Qué entra a la cola: red caída antes de conectar (DNS, conexión rechazada, sin ruta), HTTP 502/503 del balanceador sin respuesta SOAP, contingencia manual activa, y boletas o notas de boleta a las que la entidad tributaria responde 1079.

Qué recibe el POS: 200 con message = "Operation Successful en contingencia", el XML firmado, el docNumber con guión y contingencyCode 1. La contingencia manual emula una caída de internet, así que también responde 1: para el POS es lo mismo que perder la red. Ver el ejemplo 200 — En contingencia en Ejemplos de respuesta. La copia que va al Inbox lleva el motivo ContingencyTypeCode 01, caída de internet del emisor (ver Motivos de contingencia).

Ruta según el documento:

Documento	Ruta	Cadencia
Boletas (`03`) y notas de boleta (serie `BC`/`BD`)	Resumen Diario (ver abajo)	Se agrupan 60 s desde la última boleta, con un tope de 5 min; al menos 5 min entre lotes
Facturas (`01`) y notas de factura (serie `FC`/`FD`)	Reenvío automático, uno por uno	Cada 2 min la primera media hora, luego cada 10 min; antes de un segundo reenvío consulta la constancia

La serie de la nota define su ruta

Una nota de crédito o débito cuya serie no coincide con el documento que modifica —una nota de factura con serie B, o una de boleta con serie F— se rechaza antes de firmar con INVALID_REQUEST.

Qué hace el reenvío automático con cada respuesta:

Aceptado o rechazado: cierra el documento con ese veredicto e informa el estado final al Inbox.
Error interno de la entidad tributaria, credenciales o empaquetado: el documento sigue en cola y se reintenta. Los de credenciales y empaquetado avisan además a soporte de Gosocket cada 6 horas.
Respuesta incierta: se resuelve consultando la constancia.

Un documento ya entregado al POS nunca se pierde por una respuesta transitoria de la entidad tributaria.

Plazos

Los plazos se cuentan en días calendario desde el día siguiente a la emisión, en hora de Lima, y vencen a la medianoche de Lima.

Documento	Ventana	Vence (emisión el día E)
Facturas y notas de factura	3 días calendario	Al empezar el día E+4
Resumen Diario (lote de boletas de la fecha E)	7 días calendario	Al empezar el día E+8

Al vencer hay un único envío de cierre y la entidad tributaria decide. Si no lo acepta, el documento queda Rechazado por plazo: con el código de plazo de la entidad tributaria (2108, 2329, 2600, 2950) o, si no hubo respuesta formal, con el código de xPOS XPOS_PLAZO_VENCIDO. Va al Inbox en estado 3 con la nota «PLAZO» y aparece en «Documentos erróneos». No existe un estado «vencido».

📋 Resumen Diario de boletas

Las boletas de venta y notas de boleta que entran a la cola de contingencia se declaran ante SUNAT agrupadas en un Resumen Diario (lote RC), con un ciclo asincrónico propio: se envía el lote, la entidad tributaria devuelve un ticket y con ese ticket xPOS consulta después la constancia (CDR). xPOS arma y envía los lotes automáticamente, sin intervención del POS ni de la tienda.

Un lote cubre una sola fecha de emisión. Las boletas emitidas en contingencia se declaran en el lote de su fecha de emisión: una tienda que estuvo tres días en contingencia genera tres lotes.
Identificador RC-AAAAMMDD-NNNNN, con un correlativo diario y por emisor: en equipos con varios emisores cada uno lleva su propia serie de lotes. El correlativo solo se consume cuando el lote pasó el XSD: una caída de red no gasta correlativos.
El veredicto vale para todo el lote: si se acepta, cada boleta queda aceptada (estado 2 en el Inbox); si se rechaza, cada boleta queda rechazada (estado 3) con la nota del motivo.
Si el envío falla por red o por un error transitorio de la entidad tributaria, el lote queda firmado y se reintenta con el mismo identificador hasta que vence. Con el ticket en mano, xPOS consulta el CDR cada 2 minutos.
Un Fault de SUNAT al enviar el lote es un veredicto, no una caída: si es un rechazo, el lote queda Rechazado con el Fault visible.
Fault que no deja nada declarado: con 2223 (archivo ya presentado) o 0126/0127 (ticket ajeno o inexistente), el lote se rechaza y sus boletas vuelven a la cola para un lote nuevo. No requiere acción.
Vencimiento: el lote vence 7 días calendario después de la fecha de emisión que declara. Ver Plazos.
Un comprobante ya declarado en un lote aceptado no se vuelve a declarar.

Caso real: 2223 en el primer lote del día

Al instalar un onboarding nuevo en un equipo que ya emitía con ese RUC, el correlativo del día vuelve a 00001, que ya estaba presentado ante la entidad tributaria. El lote RC-…-00001 sale rechazado con 2223, xPOS reabre sus boletas y el lote siguiente, RC-…-00002, sale aceptado. No requiere acción.

Los lotes, su vencimiento y su respuesta se consultan en la vista vista Resúmenes del dashboard.

📊 Contingencias y Resúmenes en el dashboard

En el dashboard local, Perú muestra su modelo de contingencia en las vistas de documentos y suma el menú Resúmenes. La columna Estado en ET usa los estados comunes más En cola de envío, propio de Perú: el comprobante espera su envío o su respuesta desde la cola.

Contingencias y Documentos erróneos

Contingencias. Una fila por comprobante que pasó por la cola, con la columna Estado en ET y la columna Resumen, que indica en qué lote del Resumen Diario se declaró cada boleta. Ejemplo, con datos ilustrativos:

Tipo	N° Documento	Fecha	Código	Estado en ET	Resumen
03	B001-00000125	28/09/2026 15:02:11	1	En cola de envío	–
03	B001-00000124	28/09/2026 14:58:40	1	En proceso	RC-20260928-00003
03	B001-00000120	28/09/2026 12:10:05	1	Aceptado	RC-20260928-00002
01	F001-00000452	28/09/2026 11:47:30	1	Aceptado condicional	–
01	F001-00000431	24/09/2026 09:15:22	1	Rechazado	–

Documentos erróneos. Muestra los rechazos de la entidad tributaria, los errores 503 y 510 —para diagnóstico: no bloquean el reenvío del mismo número— y los cierres por plazo, con el número del comprobante.

Vista Resúmenes

Disponible desde la versión 2.7.1

Menú Resúmenes, visible solo en instalaciones de Perú. Tiene los mismos filtros que las demás vistas.

Una fila por lote del Resumen Diario:

Columna	Contenido
Resumen	Identificador del lote, `RC-AAAAMMDD-NNNNN`.
Generado	Cuándo se armó el lote.
Enviado	Cuándo se envió a la entidad tributaria; vacío mientras siga pendiente.
Vence	Fecha de vencimiento del lote. Sale en rojo si un lote abierto ya venció.
Estado en ET	Creado; Firmado, pendiente de envío; Enviado, esperando CDR; Aceptado o Rechazado.
Ticket	El ticket que devolvió la entidad tributaria.
Comprobantes	Los comprobantes declarados en el lote.

Acciones por fila: Ver XML del Resumen y Ver respuesta ET.

Ejemplo, con datos ilustrativos:

Resumen	Generado	Enviado	Vence	Estado en ET	Ticket	Comprobantes
RC-20260928-00003	28/09/2026 15:05:00	28/09/2026 15:05:02	06/10/2026 00:00	Enviado, esperando CDR	1759090302551	4
RC-20260928-00002	28/09/2026 12:15:00	28/09/2026 12:15:03	06/10/2026 00:00	Aceptado	1759079703127	12
RC-20260927-00004	27/09/2026 23:40:00	–	05/10/2026 00:00	Firmado, pendiente de envío	–	2
RC-20260926-00001	26/09/2026 10:00:00	26/09/2026 10:00:02	04/10/2026 00:00	Rechazado	1758898802004	3

🧾 Comprobante físico regularizado

Si la tienda vendió con talonario (comprobante físico), el POS lo regulariza enviándolo con el campo personalizado ContingencyTypeCode, con un valor del 02 al 07 (ver Motivos de contingencia), igual que en Costa Rica y República Dominicana. Admite facturas, boletas y notas.

<Personalizados>
  <DocPersonalizado dteID="">
    <campoString name="ContingencyTypeCode">02</campoString>
  </DocPersonalizado>
</Personalizados>

No va a la entidad tributaria ni a la cola: se valida, se firma y va al Inbox.
La respuesta es 200 con contingencyCode 3.
Un reenvío del mismo número responde como duplicado.

Motivos de contingencia (`ContingencyTypeCode`)

Catálogo de motivos de SUNAT. El 01 es el único automático: xPOS lo asigna a todo documento que entra a la cola de contingencia, incluida la contingencia manual, que emula una caída de internet. Del 02 al 07 son manuales: los envía el POS en el campo personalizado ContingencyTypeCode al regularizar un comprobante físico.

`ContingencyTypeCode`	Motivo	Tipo
`01`	Caída de internet del emisor	Automático
`02`	Fallas de fluido eléctrico	Manual
`03`	Desastres naturales	Manual
`04`	Robo	Manual
`05`	Fallas en el sistema de facturación	Manual
`06`	Venta itinerante	Manual
`07`	Otros	Manual

No confundir con el contingencyCode de la respuesta al POS, que en Perú vale 1 (automática) o 3 (manual: comprobante físico regularizado).

🔳 QR de la representación impresa

xPOS genera el QR de SUNAT (Anexo B) y lo devuelve en la respuesta, listo para imprimir:

Campo	Contenido
`barcodeText`	La cadena del QR: `RUC \| tipo \| serie \| número \| IGV \| total \| fecha \| tipo doc adquirente \| número doc adquirente \| valor resumen`
`barcodeBase64`	El QR como imagen PNG en base64
`valorResumen`	El hash del XML firmado, el mismo valor que cierra `barcodeText`

Ejemplo de barcodeText (RUC saneado):

20XXXXXXXXX|01|FCON|68|18.00|118.00|2026-10-01|6|20XXXXXXXXX|oJ8T+FnfNL/XDJUYWBWR6PrUYv8=

Si la generación del QR falla, la venta sigue.

Guías de remisión (09, 31): el QR lo entrega SUNAT dentro del CDR. xPOS lo devuelve en barcodeText y en gre.qrUrl; gre.transportEnabled es true solo cuando la guía fue aceptada y el enlace está presente.

Campos del response específicos de Perú

Perú devuelve el núcleo + eco tributario parcial (statusCode y statusMessage, sin statusDescription) + applicationResponse + timeGeneration + QR + campos propios (series, valorResumen y, en las guías, gre).

Campo	Estado	Notas
`statusCode` / `statusMessage`	✓	Leídos de la CDR. `statusCode: "0"` = comprobante aceptado. En contingencia no viene `statusCode`, y `statusMessage` trae el motivo de la contingencia.
`statusDescription`	–	No se emite en Perú.
`applicationResponse`	✓	La CDR en base64. En un rechazo trae el CDR o el Fault de la entidad tributaria; en una duplicidad, el CDR guardado. En contingencia no viene.
`countryIdentificationCode`	✓	El serie-correlativo del comprobante, igual a `docNumber`. Perú no tiene un identificador adicional asignado por la entidad tributaria.
`series`	✓	La serie del comprobante (`F001`). Campo propio de Perú.
`timeGeneration`	✓	ISO 8601.
`timeValidation`	–	No se emite en Perú.
`barcodeText` / `barcodeBase64`	✓	El QR de SUNAT: la cadena y la imagen PNG en base64.
`valorResumen`	✓	El hash del XML firmado. Campo propio de Perú.
`gre.qrUrl` / `gre.transportEnabled`	✓	Solo en las guías de remisión (`09`, `31`).
`contingencyCode`	✓	`1` = contingencia automática (sin red; también la contingencia manual del dashboard, que emula una caída de internet); `3` = contingencia manual (comprobante físico regularizado). El motivo va en `ContingencyTypeCode`. En los errores llega como la cadena `"null"`.
`custom_response`	–	Llega como la cadena `"null"`: la salida Personalizada de Perú opera en `GET /api/v1/status`, no en la emisión.
`partnerNumber`	–	No aplica en Perú.

Errores de la entidad tributaria, legibles

Los servicios de SUNAT y del OSE responden en SOAP: una falla del lado de la entidad tributaria no llega como error HTTP sino como un SOAP Fault dentro de una respuesta técnicamente exitosa. xPOS extrae el código y la descripción del Fault, de modo que:

Un comprobante rechazado por la entidad tributaria no queda marcado como enviado con éxito.
El motivo llega al POS (error_description, con el código adelante), al dashboard y al portal en forma legible.
El código HTTP de la respuesta clasifica el caso: 503, 510 o 400.

El catálogo de etapas y la clasificación de los códigos de SUNAT/OSE están en Códigos de errores · Perú.

Notas particulares

Publica en Inbox-Gosocket (o por el canal System Integrator cuando la organización lo tenga habilitado).
Reobtención vía GET /api/v1/status con transactionId o con docNumber + typeDoc. Para Perú, docNumber es el serie-correlativo con guión (F001-00000001). Con más de un emisor instalado, la consulta por número exige además origin.
El emisor se valida contra origin: si el RUC del emisor dentro del documento no coincide con el origin de la petición, la emisión falla en VALIDATE_ISSUER_STAGE.
Anulaciones: POST /api/v1/cancelation-event no aplica a Perú. La anulación de un comprobante peruano se declara ante SUNAT mediante una Comunicación de Baja, que viaja por el mismo ciclo asíncrono por ticket que el Resumen Diario y la construye la propia plataforma — su habilitación está en preparación; no existe hoy un parámetro con el que el POS pueda solicitar una baja. Coordina los casos de anulación con tu contacto de Gosocket.
Datos personalizados del cliente: viajan en el nodo <Personalizados>, que contiene un <DocPersonalizado> con los campos campoString. Desde la versión 2.7.1, el XML firmado que recibe el POS (output / signedXml) y el que muestra «Ver documento» en el dashboard traen los Personalizados de vuelta.

<Personalizados>
  <DocPersonalizado dteID="">
    <campoString name="Mail1">…</campoString>
  </DocPersonalizado>
</Personalizados>