Manual+de+Programador

Manual%2Bde%2BProgramador

User Manual: Pdf

Open the PDF directly: View PDF .
Page Count: 54

Download
Open PDF In Browser	View PDF

MANUAL
DEL PROGRAMADOR

Emisión electrónica desde los
Sistemas del Contribuyente
RS 097-2012/SUNAT y modificatorias

SUPERINTENDENCIA NACIONAL DE ADUANAS Y ADMINISTRACIÓN
TRIBUTARIA SUNAT - Lima – Perú
Setiembre 2016

SEE –Sistemas del Contribuyente Manual del programador

~2~

SEE –Sistemas del Contribuyente Manual del programador

INDICE
1

Documentos electrónicos .........................................................................................6
1.1

Lineamientos generales ....................................................................................6

1.2

Nombre del documento XML y archivos ZIP ......................................................6

1.3

Contenido del archivo ZIP ...............................................................................10

1.4

Contenido del archivo XML..............................................................................11

Envío de documentos electrónicos .........................................................................12
2.1

Mecanismo de envío: WebServices .................................................................12

2.2

Mecanismo de seguridad: WS-Security y SSL.................................................13

2.3

Servicio Beta ...................................................................................................14

2.4

Tipos de envío .................................................................................................14

2.5

Métodos disponibles ........................................................................................15

2.6

Constancia de Recepción (CDR) .....................................................................23

2.7

Recuperación de la Constancia de Recepción ................................................24

2.8

Servicios de consulta.......................................................................................25

Firma Digital ...........................................................................................................26
3.1

Consideraciones sobre el certificado digital a utilizarse ...................................26

3.2

Consideraciones sobre el proceso de firmado .................................................26

Procedimientos específicos ....................................................................................28
4.1

Manejo de errores ...........................................................................................28

4.2

Utilización de campos del estándar UBL .........................................................29

4.3

PROCESO DE CONTINGENCIA ....................................................................30

4.3.1

Factura, boleta de venta, notas de crédito y débito y tickets ........................30

4.3.2

Comprobantes de Retención y Percepción ..................................................31

ANEXO 1: Constancia de Recepción.............................................................................34
A.

Información contenida en la Constancia de Recepción y estructura XML ........34
A.1

Campos contenidos en la Constancia de Recepción ........................... 35

A.2

Estructura XML de ApplicationResponse según norma UBL................ 36

Elementos de la Constancia de Recepción .....................................................39
~3~

SEE –Sistemas del Contribuyente Manual del programador

B.1

ext:UBLExtensions .............................................................................. 39

B.2

cbc:UBLVersionID ............................................................................... 40

B.3

cbc:CustomizationID ............................................................................ 40

B.4

cbc:ID .................................................................................................. 40

B.5

cbc:IssueDate ...................................................................................... 40

B.6

cbc:IssueTime...................................................................................... 40

B.7

cbc:ResponseDate .............................................................................. 41

B.8

cbc:ResponseTime .............................................................................. 41

B.9

cac:Signature ....................................................................................... 41

B.10

cbc:Note .............................................................................................. 42

B.11

cac: SenderParty ................................................................................. 42

B.12

cac: ReceiverParty ............................................................................... 43

B.13

cac: DocumentResponse ..................................................................... 43

Ejemplos ......................................................................................................47
C.1

Respuesta de aplicación SUNAT – Estado ACEPTADO...................... 47

C.2

Respuesta de aplicación SUNAT – Estado RECHAZADO ................... 49

C.3

Respuesta de aplicación SUNAT – Excepción en producción.............. 51

ANEXO 2: SERVICIO WEB CONSULTA DE FACTURAS Y NOTAS ............................52

~4~

SEE –Sistemas del Contribuyente Manual del programador

Registros de Cambios del Manual

Fecha

Versión

Elemento

de Motivo de Cambio

Cambio
31/05/2012

1.0

25/06/2012

1.1

Anexo 2

Incorporación de listado de errores

1.2

Modificaciones

Modificación de ruta del servidor.

31/08/2016

2.0

Incorporación

documentos

electrónicos

~5~

SEE –Sistemas del Contribuyente Manual del programador

Documentos electrónicos

Los documentos electrónicos están especificados en formato XML y basados en el
estándar UBL 2.0 (http://docs.oasis-open.org/ubl/os-UBL-2.0/UBL-2.0.html). Para su
envío a la SUNAT, se debe tener en cuenta las especificaciones descritas en este
manual. El documento será rechazado en caso se incumplan éstas.
1.1

Lineamientos generales
1) Los documentos XML antes de ser enviados a la SUNAT, deberán ser
empaquetados en un archivo ZIP.
2) Los documentos XML deberán tener un nombre.
3) El envío de los archivos ZIP, indicados en el punto 1, será vía WebServices.
4) El servicio Web estará protegido con un esquema de seguridad basado en
WSSecurity.
5) El modelo de seguridad usado en WSSecurity será UsernameToken y sólo se
aceptará las credenciales de la Clave SOL de la SUNAT.

1.2

Nombre del documento XML y archivos ZIP
Los documentos XML y los archivos ZIP que lo contienen, deben ser generados
con los nombres que se detallan a continuación, según el documento que
corresponda enviar
a) Factura y sus Notas de Crédito y Débito
Posición
01-11
12
13-14

Nemotécnico
RRRRRRRRR
RR
TT
01
03
07
08
FAAA ó
BAAA

Descripción
Ruc del Emisor

20
21-28

CCCCCCCC

29 (*)
30-32 (*)

.
EEE

Guión separador
Tipo de comprobante
Factura Electrónica
Boleta de venta
Nota de Crédito
Nota de Débito
Guión separador
Serie del comprobante. Se espera que el primer
carácter sea la constante “F” seguido por 3
caracteres alfanuméricos para las Facturas y Notas
asociadas ó B seguido de 3 caracteres para las
Boletas de venta y Notas asociadas.
Guión separador
Numero correlativo del comprobante. Este campo es
variante, se espera un mínimo de 1 y máximo de 8.
Punto de extensión
Extensión del archivo

XML

Para el caso del documento XML

15
16-19

~6~

SEE –Sistemas del Contribuyente Manual del programador
ZIP

Para el caso del archivo ZIP

(*) Las posiciones pueden variar dependiendo de la longitud variante del correlativo.
Ejemplos:
Nombre del archivo ZIP: 20100066603-01-F001-1.ZIP
Nombre del archivo XML: 20100066603-01-F001-1.XML
Nombre del archivo ZIP: 20100066603-01-F001-00000001.ZIP
Nombre del archivo XML: 20100066603-01-F001-00000001.XML
Nombre del archivo ZIP: 20100066603-07-F001-1.ZIP
Nombre del archivo XML: 20100066603-07-F001-1.XML
Nombre del archivo ZIP: 20100066603-08-F001-1.ZIP
Nombre del archivo XML: 20100066603-08-F001-1.XML

b) Comunicación de baja:
Posición
01-11
12
13-14

Nemotécnico
RRRRRRRRRR
R
TT
RA
YYYYMMDD

Descripción
RUC del emisor electrónico

Guión separador
Tipo de resumen
Comunicación de Baja
15
Guión separador
16-23
Fecha de la generación del archivo en formato
YYYYMMDD
24
Guión separador
25-29
CCCCC
Numero correlativo. Este campo es variante, se espera un
mínimo de 1 y máximo de 5.
30 (*)
.
Punto de extensión
31-33(*)
EEE
Extensión del archivo
XML
Para el caso del formato XML
ZIP
Para el caso del archivo ZIP
(*) Las posiciones pueden variar dependiendo de la longitud del correlativo.
Ejemplo:
Nombre del archivo ZIP: 20100066603-RA-20110522.ZIP
Nombre del archivo XML: 20100066603-RA-20110522.XML

c) Resumen Diario
Posición
01-11
12
13-14
15
16-23

Nemotécnico
RRRRRRRRRR
R
TT
RC
YYYYMMDD

Descripción
RUC del emisor electrónico
Guión separador
Tipo de resumen
Resumen Diario
Guión separador
Fecha de la generación

del

archivo

formato
~7~

SEE –Sistemas del Contribuyente Manual del programador
YYYYMMDD. Fecha que corresponde a la fecha de
emision de la boletas y notas vinculadas
24
Guión separador
25-29
CCCCC
Numero correlativo. Este campo es variante, se espera un
mínimo de 1 y máximo de 5.
30 (*)
.
Punto de extensión
31-33(*)
EEEE
Extensión del archivo, puede contener 4 o cuatro
31-34(*)
caracteres
XML
Para el caso del formato XML
ZIP
Para el caso del archivo ZIP
(*) Las posiciones pueden variar dependiendo de la longitud del correlativo.
Ejemplo:
Nombre del archivo ZIP: 20100066603-RC-20110522.ZIP
Nombre del archivo XML: 20100066603-RC-20110522.XML

IMPORTANTE: A partir del 01 de enero de 2017, considerando la nueva estructura
detallada del RESUMEN DIARIO (nuevo Anexo 5), el Resumen Diario deberá enviarse en
bloques de 1,000 líneas. Cada bloque corresponderá a un número correlativo diferente.
Los envíos son complementarios, es decir, no sustituyen al anteriormente enviado para el
mismo día.

d) Comprobante
de
individualmente
Posición
01-11
12
13-14

percepción/retención

Nemotécnico
RRRRRRRRRR
R
TT
40
20
PAAA ó
RAAA

electrónico

enviado

Descripción
RUC del emisor electrónico

Guión separador
Tipo de comprobante
Comprobante de Percepción
Comprobante de Retención
15
Guión separador
16-19
Serie del comprobante. Se espera que el primer carácter
sea la constante “P” seguido por 3 caracteres
alfanuméricos para los comprobantes de percepción ó “R”
seguido de 3 caracteres alfanuméricos para los
comprobantes de retención.
20
Guión separador
21-28
CCCCCCCC
Número correlativo del comprobante. Este campo es
variante, se espera un mínimo de 1 y máximo de 8.
29 (*)
.
Punto de extensión
30-32 (*)
EEE
Extensión del archivo
XML
Para el caso del formato XML
ZIP
Para el caso del archivo ZIP
(*) Las posiciones pueden variar dependiendo de la longitud del correlativo.
Ejemplo:
Nombre del archivo ZIP: 20100066603-40-P001-1.ZIP
Nombre del archivo XML: 20100066603-40-P001-1.XML

e) Resumen diario de reversión de los comprobantes de percepción y
retención:

~8~

SEE –Sistemas del Contribuyente Manual del programador
Posición
01-11

15
16-23

Nemotécnico
RRRRRRRRRR
R
TT
RR
YYYYMMDD

24
25-29

CCCCC

30 (*)
31-33 (*)

.
EEE
XML
ZIP

12
13-14

Descripción
RUC del emisor electrónico
Guión separador
Tipo de resumen
Resumen de reversión
Guión separador
Fecha de la generación del archivo en formato
YYYYMMDD
Guión separador
Número correlativo del archivo. Este campo es variante,
se espera un mínimo de 1 y máximo de 5.
Punto de extensión
Extensión del archivo
Para el caso del documento XML
Para el caso del archivo ZIP

(*) Las posiciones pueden variar dependiendo de la longitud variante del correlativo.
Ejemplos:
Nombre del archivo ZIP: 20100066603-RR-20150522-1.ZIP
Nombre del archivo XML: 20100066603-RR-20150522-1.XML

f) Guía de Remisión
Posición
01-11
12
13-14

Nemotécnico
RRRRRRRRRR
R
TT
09
31
T###

Descripción
RUC del emisor electrónico

Guión separador
Tipo de guía de remisión electrónica
Guía de remision transportista
Guía de remisión remitente
15
Guión separador
16-19
Serie de la guía de remisión electrónica. Se espera que el
primer carácter sea la constante “T” seguido por tres
caracteres alfanuméricos.
20
Guión separador
21-28
CCCCCCCC
Número correlativo de la guía de remisión electrónica.
Este campo es variante. Se espera un mínimo de 1 y
máximo de 8 dígitos.
29 (*)
.
Punto de extensión
30-32 (*)
EEE
Extensión del archivo
XML
Para el caso del formato XML
ZIP
Para el caso del archivo ZIP
(*) Las posiciones pueden variar dependiendo de la longitud del correlativo.
Ejemplo:
Nombre del archivo ZIP: 20100066603-09-T001-1.ZIP
Nombre del archivo XML: 20100066603-09-T001-1.XML

g) Lotes de Facturas, notas de crédito y notas de débito electrónicas
Posición
01-11
12

Nemotécnico
RRRRRRRRRR
R
-

Descripción
RUC del emisor electrónico
Guión separador
~9~

SEE –Sistemas del Contribuyente Manual del programador
13-14

TT
LT

Tipo de Lotes.
Lotes de Factura, notas de crédito y notas de débitos
electrónicas.

15
16-23

YYYYMMDD

24
25-29

CCCCC

30 (*)
31-33 (*)

.
EEE
ZIP

Guión separador
Fecha de la generación del archivo en formato
YYYYMMDD
Guión separador
Número correlativo del archivo. Este campo es variante,
se espera un mínimo de 1 y máximo de 5.
Punto de extensión
Extensión del archivo
Para el caso del archivo ZIP

(*) Las posiciones pueden variar dependiendo de la longitud variante del correlativo.
Ejemplos:
Nombre del archivo ZIP: 20100066603-LT-20160504-1.ZIP
Nombre del archivo ZIP: 20100066603-LT-20160504-2.ZIP

1.3

Contenido del archivo ZIP
El contenido del archivo ZIP dependerá de la modalidad de envío, la cual deberá
ser de la siguiente manera:
-

En caso de las facturas y sus correspondientes notas de crédito y
débito,comprobante de retención, comprobante de percepción y guía de
remisiónse enviaráun único comprobante, razón por la que se espera recibir
un único archivo ZIP y dentro de este, una carpeta de nombre dummy (vacio)
y un documento XML. Los nombres de los archivos deben coincidir a
excepción de la extensión. Por ejemplo:
o Nombre del archivo ZIP: 20100066603-01-F001-1.ZIP
o Nombre del archivo XML: 20100066603-01-F001-1.XML

En el caso del Resumen Diario de boletas de venta y sus correspondientes
notas de crédito y débito y Comunicación de baja, se espera recibir un único
archivo ZIP y dentro de este, una carpeta de nombre dummy (vacio) y un
documento XML de Resumen o Baja. Los nombres de los archivos deben
coincidir a excepción de la extensión. Por ejemplo:
Para los archivos de resumen de boletas de venta y sus notas de crédito y
débito.
o Nombre del archivo ZIP: 20100066603-RC-20110522-1.ZIP
o Nombre del archivo XML: 20100066603-RC-20110522-1.XML
Para los archivos de Comunicación de Bajas
o Nombre del archivo ZIP: 20100066603-RA-20110522-002.ZIP
o Nombre del archivo XML: 20100066603-RA-20110522-002.XML

En el caso lotes de facturas, notas de créditos y notas de débitos electrónicas,
se espera recibir un único archivo ZIP y dentro de este, varios (con un máximo
de 500)documentos XML entre facturas, notas de crédito o notas de débito.
Los nombres de los archivos deben corresponder a un mismo número de RUC
(emisor del lote) debe coincidir con el tipo de documento a declarar (facturas,
notas de débito o notas de crédito). Por ejemplo:
~ 10 ~

SEE –Sistemas del Contribuyente Manual del programador

Para los archivos de lotes de facturas, notas de crédito y notas de débito
electrónicas.
o Nombre del archivo ZIP: 20100066603-LT-20160820-1.ZIP
o Contenido:
 Archivo XML: 20100066603-07-F001-1.XML
 Archivo XML: 20100066603-08-F001-1.XML
 Archivo XML: 20100066603-01-F001-1.XML
 …
1.4

Contenido del archivo XML
El contenido del archivo XML deberá cumplir con lo siguiente:
a. La estructura de cada documento deberá construirse de acuerdo a los
esquemas (.xsd) definidos para cada tipo de documento.
b. La información consignada debe cumplir las reglas de negocio definidas en la
normatividad vigente. Estas especificaciones se encuentran detalladas en las
“Guías de Elaboración de documentos electrónicos XML” publicadas en la
página web de SUNAT.
c. En el caso de utilizarse acentos o letras propias del alfabeto español como la
eñe, se debe generar el archivo XML con la codificación ISO-8859-1. Además
se debe especificar en la primera línea del archivo xml el uso de dicha
codificación para su correcto procesamiento:

~ 11 ~

SEE –Sistemas del Contribuyente Manual del programador

2.1

Envío de documentos electrónicos

Mecanismo de envío: WebServices
Los WebServices permiten la comunicación entre aplicaciones o componentes de
aplicaciones de forma estándar a través de protocolos comunes como http(s) y de
manera independiente al lenguaje de programación, plataforma de implantación,
formato de presentación o sistema operativo. Un WebService es un contenedor
que encapsula funciones específicas y hace que estas funciones puedan ser
utilizadas en otros servidores.
La SUNAT ha determinado que la forma de envío de los comprobantes
electrónicos se realice vía WebServices. En tal sentido, también se han definido
métodos personalizados para recibir cada tipo de documento, los mismos que se
detallan en el punto 2.4 del presente documento.
El servicio Web será protegido vía SSL y estará publicado en las direcciones que
se detallan a continuación, según el tipo de documento a enviar:
Servicios Web disponibles en producción

SERVICIO
Factura.
Notas vinculadas.
Servicios Públicos.
Resumen Diario.
Comunicación de Baja.
Lotes de Facturas.
Retención y Percepción
Resumen de Reversión de
comprobantes
de
percepción o retención.
Guía
de
Remisión
Remitente Electrónica

DIRECCION

https://e-factura.sunat.gob.pe/ol-ti-itcpfegem/billService?wsdl

https://www.sunat.gob.pe/ol-ti-itemision-otroscpegem/billService?wsdl
https://e-guiaremision.sunat.gob.pe/ol-ti-itemision-guia-gembeta/billService?wsdl

Servicios Web disponibles en beta
SERVICIO
Factura.
Notas vinculadas.
Servicios Públicos.
Resumen Diario.
Comunicación de Baja.
Lotes de Facturas.
Retención y Percepción
Resumen de Reversión de
comprobantes de percepción
o retención.

DIRECCION

https://e-factura.sunat.gob.pe/ol-ti-itcpfegem/billService?wsdl

https://www.sunat.gob.pe/ol-ti-itemision-otroscpe-gem/billService?wsdl

~ 12 ~

SEE –Sistemas del Contribuyente Manual del programador

Guía de Remisión Remitente
Electrónica

https://e-guiaremision.sunat.gob.pe/ol-ti-itemision-guia-gembeta/billService?wsdl

Para envío en el proceso de homologación:
https://www.sunat.gob.pe/ol-ti-itcpgem-sqa/billService

2.2

Mecanismo de seguridad: WS-Security y SSL
WS-Security (Seguridad en Servicios Web) es un protocolo de comunicaciones
que suministra un medio para aplicar seguridad a los Servicios Web. WS-Security
incorpora las características de seguridad en el encabezado de un mensaje
SOAP.
La especificación WS-Security permite una variedad de formatos de firma digital,
algoritmos de cifrado y dominios de confianza, y está abierta a diferentes modelos
de seguridad, como por ejemplo:






X.509 certificates
Kerberos tickets
UserID/Password credentials
SAML-Assertion
Custom defined token

SOAP Envelope
Security Feeder
SOAP Envelope
SOAP Body

Security Token
Signature
SOAP Body

Para acceder al Servicio Web de la SUNAT se ha determinado el uso del WS-Security
en el modelo UsernameToken. En donde se debe consignar las credenciales de la
Clave SOL, de la siguiente manera:

~ 13 ~

SEE –Sistemas del Contribuyente Manual del programador

20100066603MODDATOS
moddatos

Como la modalidad UsernameToken solo permite consignar dos campos que son
Username y Password y sin embargo la Clave SOL está compuesta de 3 campos que
son RUC, usuario y contraseña, se debe concatenar los campos RUC y usuario en el
campo Username. La contraseña se consignará en el campo Password.
La clave SOL que se utilizará debe cumplir con los siguientes requisitos:
- Debe ser una clave de tipo secundaria
- Tener asignado el perfil de “Envío de documentos electrónicos-Grandes
emisores”
Además se hará uso del protocolo SSL en conjunto con HTTPS, con el cual la
información que se transfiera desde el servidor del emisor electrónico hacia el servidor
de SUNAT, viajará en forma cifrada.
2.3

Servicio Beta

Es un servicio de pruebas alternativo, a fin de que los contribuyentes puedan realizar pruebas de
manera alternativa o previa al proceso en producción.
Este servicio, solo permite realizar pruebas de las estructuras XML de los diferentes documentos
electrónicos implementados Para el uso de este servicio no es necesario contar con un
certificado digital registrado en SUNAT.
Para efectos de la autenticación utilizar las siguientes credenciales:
Usuario = [RUC] MODDATOS
Password: MODDATOS
Donde [RUC] es el número de RUC del emisor.

2.4

Tipos de envío
Se han establecido dos tipos de envíos: Síncrono y Asíncrono.
Envío Síncrono
En este tipo de envío, el servicio web de SUNAT procesa el documento remitido
por el emisor y responde inmediatamente con una constancia de recepción (CDR)
que puede ser de aceptación o rechazo. Bajo esta modalidad se procesarán las
facturas y las notas de crédito y débito asociadas.

~ 14 ~

SEE –Sistemas del Contribuyente Manual del programador

Envío Asíncrono
Este tipo de envío será utilizado para el caso del Resumen diario de Boletas de
Venta y sus notas de crédito y debito asociadas así como la Comunicación de
Baja. El servicio web de SUNAT recibirá el archivo a procesar y devolverá un
número de ticket de atención, con el cual el emisor podrá consultar el resultado
del proceso.

2.5

Métodos disponibles
2.5.1

Para envió en producción y en el proceso de homologación.

El servicio web de recepción cuenta con un método personalizado para aceptar
cada tipo de documento electrónico. Los métodos de recepción definidos son los
siguientes:
-

sendBill, este método recibe un archivo ZIP con un único documento XML de
comprobante y devuelve un archivo Zip que contiene un documento XML que es
la constancia de aceptación ó rechazo.

~ 15 ~

SEE –Sistemas del Contribuyente Manual del programador

sendSummary, este método recibe un archivo Zip con un único documento XML
de resúmenes, ya sea resumen de boletas o comunicación de bajaso
reversiones de comprobantes de percepción y retención. Devuelve un ticket con
el que posteriormente utilizando el método getStatus se puede obtener el archivo
Zip que contiene un documento XML que es la constancia de aceptación o
rechazo.

sendPack, este método recibe un archivo Zip con un varios documentos XML,
ya sean de facturas, boletas de venta, notas de crédito y notas de débito.
Devuelve un ticket con el que posteriormente utilizando el método getStatus se
puede obtener el archivo Zip que contiene varios documentos XML que es la
constancia de aceptación o rechazo por documento enviado y un archivo
resumen.

getStatus, este método recibe el ticket como parámetro y devuelve un objeto
que indica el estado del proceso y en caso de haber terminado, devuelve adjunta
la constancia de aceptación o rechazo.

A continuación se detalla el uso de cada uno de los métodos definidos:

sendBill
El método sendBill recibe como parámetro un nombre de archivo especificado por la
SUNAT y el contenido de un archivo ZIP con un único documento XML de comprobante
y devuelve un archivo Zip que contiene un documento XML que es la constancia de
aceptación ó rechazo.

Parámetros de entrada
Tipo
Parámetro
String
Nombre del archivo

Comentario
Se debe consignar el nombre del
archivo
de
acuerdo
a
la
especificación de la SUNAT. Por
ejemplo:
20100066603-01-F001-1.ZIP

~ 16 ~

SEE –Sistemas del Contribuyente Manual del programador

byte[]

Contenido del archivo ZIP

Se debe consignar el contenido del
archivo ZIP en un arreglo de bytes.

TODOS los parámetros de entrada son obligatorios, de no ingresar alguno o ingresar
valores nulos el servicio emitirá una excepción.
Retorno
Tipo
byte[]

Comentario
Devuelve un arreglo de bytes que es un archivo ZIP que
contiene el documento XML de la constancia de aceptación o
rechazo.

Ejemplo SOAP para invocar el servicio:

20100066603MODDATOS
moddatos

20100066603-01-F001-1.zip
cid:20100066603-01-F001-1.zip

sendSummary
El método sendSummary recibe como parámetro un nombre de archivo especificado
por la SUNAT y el contenido de un archivo ZIP con un único documento XML de
resúmenes, ya sea resumen de boletas o resumen de bajas o resumen de reversiones
de comprobantes de retención y percepción. Devuelve un ticket con el que
posteriormente utilizando el método getStatus se puede obtener la constancia de
aceptación o rechazo.

~ 17 ~

SEE –Sistemas del Contribuyente Manual del programador

Parámetros de entrada
Tipo
Parámetro
String
Nombre del archivo

byte[]

Contenido del archivo ZIP

Comentario
Se debe consignar el nombre del
archivo de acuerdo a la especificación
de la SUNAT. Por ejemplo:
20100066603-RC-20110522.ZIP
Se debe consignar el contenido del
archivo ZIP en un arreglo de bytes.

TODOS los parámetros de entrada son obligatorios, de no ingresar alguno o ingresar
valores nulos el servicio emitirá una excepción.
Retorno
Tipo
String

Comentario
Retorna el ticket de proceso, con el que posteriormente
utilizando el método getStatus se puede obtener el archivo
Zip que contiene un documento XML que es la constancia de
aceptación o rechazo

Ejemplo SOAP para invocar el servicio:

20100066603MODDATOS
moddatos

20100066603-RC-20110522-1.zip
cid:20100066603-RC-20110522-1.zip

~ 18 ~

SEE –Sistemas del Contribuyente Manual del programador

sendPack
El método sendPackrecibe como parámetro un nombre de archivo especificado por la
SUNAT y el contenido de un archivo ZIP con varios documentos XML, ya sean facturas
o notas de crédito o notas de débitos. Devuelve un ticket con el que posteriormente
utilizando el método getStatus se puede obtener la constancia de aceptación o rechazo
de cada documento.

Parámetros de entrada
Tipo

Parámetro

Comentario

String

Nombre del archivo

Se debe consignar el nombre del
archivo de acuerdo a la especificación
de la SUNAT. Por ejemplo:

byte[]

20100066603-LT-20160822.ZIP
Se debe consignar el contenido del

Contenido del archivo ZIP

archivo ZIP en un arreglo de bytes.
TODOS los parámetros de entrada son obligatorios, de no ingresar alguno o ingresar
valores nulos el servicio emitirá una excepción.
Retorno
Tipo

Comentario

String

Retorna el ticket de proceso, con el que posteriormente
utilizando el método getStatus se puede obtener el archivo
Zip

que

contiene

los

documentos

XML

que

son

las

constancias de aceptación o rechazo por cada documento
enviado.
Ejemplo SOAP para invocar el servicio:

20100066603MODDATOS
moddatos

~ 19 ~

SEE –Sistemas del Contribuyente Manual del programador

20100066603-LT-20160822-1.zip
cid:20100066603-LT-20160822-1.zip

getStatus
El método getStatus recibe como parámetro el número de ticket de procesamiento y
devuelve un objeto que indica el estado del proceso y en caso de haber terminado
correctamente o con errores, adjunta la(s) constancia(s) de aceptación o rechazo
respectivamente y el reporte de envio (para el caso de lotes).

Parámetros de entrada
Tipo
Parámetro
String
ticket

Comentario
Es
el
ticket
de
procesamiento que fue
devuelto
por
algún
método asíncrono, como
lo
es
sendSummaryo
sendPack.

TODOS los parámetros de entrada son obligatorios, de no ingresar alguno o ingresar
valores nulos el servicio emitirá una excepción.
Retorno
Tipo
StatusResponse

Comentario
Es un objeto que contiene la respuesta del procesamiento. El
objeto StatusResponse tiene dos atributos:
statusCode: Indica el estado del procesamiento, es del tipo
String y puede tener los siguientes valores:
0 = Procesó correctamente
98 = En proceso
99 = Proceso con errores
content: Únicamente si el atributo statusCode tiene los
valores 0 ó 99, este campo tendría valores, que son la(s)
constancia(s) de aceptación o rechazoy el reporte de envio
(para el caso de lotes), empaquetados en un archivo ZIP.
~ 20 ~

SEE –Sistemas del Contribuyente Manual del programador

Ejemplo SOAP para invocar el servicio:

20100066603MODDATOS
moddatos

201100000011227

Y esto es lo que esperaríamos que responda:

content>
0

getStatusCdr
El método getStatusCdrrecibe como parámetro los datos de Comprobante de pago
(ruc del emisor, tipo de comprobante, serie y numero de comprobante) y devuelve un
objeto que indica el estado del Cdr y en caso de haber terminado correctamente,
adjunta la Cdr.

Parámetros de entrada
Tipo
Parámetro
String
rucComprobante

Comentario
Es
el
ruc
del
emisor
del
comprobante de pago a consultar.
~ 21 ~

SEE –Sistemas del Contribuyente Manual del programador

String

tipoComprobante

String

serieComprobante

String

numeroComprobante

Es el tipo de comprobante a
consultar.
01: Factura.
07: Nota de crédito.
08: Nota de débito.
Es la serie del comprobante a
consultar.
Es el número de comprobante a
consultar.

TODOS los parámetros de entrada son obligatorios, de no ingresar alguno o ingresar
valores nulos el servicio emitirá una excepción.
Retorno
Tipo
byte[]

Comentario
Devuelve un arreglo de bytes que es un archivo ZIP que
contiene el documento XML de la constancia de recepción
(CDR).

Ejemplo SOAP para invocar el servicio:

20524119553MODDATOS
moddatos

20520485750
01
FF02
125

Y esto es lo que esperaríamos que responda:

~ 22 ~

SEE –Sistemas del Contribuyente Manual del programador

content>
0

2.6

Constancia de Recepción (CDR)
El documento electrónico de respuesta de SUNAT para todos los documentos
electrónicos enviados es la Constancia de Recepción (CDR). Este documento
informa al emisor el resultado del envío, y podrá tener el estado de aceptada o
rechazada. Las implicancias de la aceptación o rechazo se explican en el numeral
4.1 del presente manual.
La constancia de recepción ha sido clasificada en tres tipos de acuerdo al
documento electrónico enviado:
- CDR- Factura y nota, cuando corresponde al resultado del envío de una
Factura y/o Nota de crédito y débito relacionadas
- CDR-Resumen Diario, cuando corresponde al resultado del Resumen
diario de boletas de venta y notas de crédito y debito electrónicas
relacionadas.
- CDR – Baja, cuando corresponde al resultado de la Comunicación de baja.
- CDR – Resumen de Reversión, cuando corresponde al resultado del
Resumen diario de reversiones de comprobantes de retención y
percepción.
Sin embargo, para el sistema, todos los tipos de constancias son iguales, es decir,
tienen la misma estructura y por lo tanto, contienen la misma información.
Las características generales de la constancia son las siguientes:
-

Formato y estructura:
Tendrá formato XML basado en el documento ApplicationResponse de UBL
versión 2.0. En el Anexo 1 del presente manual se encuentra el detalle de los
elementos utilizados para el caso peruano.

Nombre:
La constancia de recepción es devuelta por el servicio web de SUNAT dentro
de un archivo zip. Al desempaquetar dicho archivo, se encontrará la
constancia con el siguiente formato de nombre:
R-.xml
~ 23 ~

SEE –Sistemas del Contribuyente Manual del programador

Ejemplos:

2.7

Archivo XML enviado

Constancia de Recepción

20199872761-01-FR92-9882.xml

R-20199872761-01-FR92-9882.xml

20199872761-07-FC92-762.xml

R-20199872761-07-FC92-762.xml

20199872761-RC-20120601-1.xml

R-20199872761-RC-20120601-1.xml

20199872761-RA-20120601-1.xml

R-20199872761-RA-20120601-1.xml

Firma digital:
Todas las constancias se encontrarán firmadas digitalmente por SUNAT.
Recuperación de la Constancia de Recepción
Para los resúmenes diarios y comunicaciones de baja (envío asíncrono), la
recuperación de la constancia se efectuará invocando el servicio web de consulta
del estado del proceso de envío. En la medida de que el proceso de recepción
haya concluido, el sistema devolverá la constancia de recepción correspondiente
al proceso asociado al número de ticket consultado.
Para realizar la consulta de Constancia de Recepción de SUNAT (CDR-SUNAT),
se efectuará invocando al servicio web de consulta de CDR de producción, podrá
ser obtenida enviado información del documento electrónico (RUC Emisor, tipo,
serie y número del comprobante), el sistema devolverá la constancia de recepción
correspondiente al proceso asociado a la información del documento electrónico
consultado.
2.7.1 Para consulta o recupero de CDR en producción de Factura, nota de
crédito o debito
getStatusCdr: Este método recibe los datos de un CDP (Ruc del emisor, tipo de
comprobante, serie y número) como parámetro y devuelve un objeto que indica
el estado del proceso y en caso de haber terminado, devuelve adjunto el CDR.
2.7.2
Para consulta de CDR en producción de Resumen Diario o
Comunicación de Baja o Resumen de Reversiones o Lotes de Facturas.
getStatus (del ticket), este método recibe los datos de un ticket como
parámetro y devuelve un objeto que indica el estado del proceso y en caso de
haber terminado, devuelve adjunto el CDR.

~ 24 ~

SEE –Sistemas del Contribuyente Manual del programador

2.8

Servicios de consulta

Se ha puesto disposición servicios automáticos de consulta de validez del documento
electrónico (XML), así como del estado del envío de documentos

Servicio
Consultas de validez y
verificación de facturas electrónicas

Dirección
https://www.sunat.gob.pe/ol-itwsconsvalidcpe/billValidService?wsdl

Consulta de CDR y estado de envío https://www.sunat.gob.pe/ol-it(VER INSTRUCCIONES EN ANEXO 2) wsconscpegem/billConsultService?wsdl

~ 25 ~

SEE –Sistemas del Contribuyente Manual del programador

Firma Digital
Todos los documentos electrónicos que se enviarán a SUNAT deberán ser firmados
digitalmente por el emisor, haciendo uso de un certificado digital. Las
características que se deben cumplir se detallan a continuación:
3.1

Consideraciones sobre el certificado digital a utilizarse
a) El certificado debe cumplir con los siguientes requisitos técnicos:
 Formato estándar X.509 v3.
 Longitud mínima de clave privada de 1024 bits
 Permitir que se identifique al titular de la Firma digital, señalando
nombre y apellidos y DNI, y el número de RUC de la empresa que
representa.
 El número de RUC deberá estar consignado en el campo OU
(Organizational Unit) del atributo Subject Name.
El proveedor de los certificados digitales, deberá identificar a los titulares y/o
suscriptores del certificado digital mediante el levantamiento de datos y la
comprobación dela información brindada por el referido titular.
b) El certificado digital deberá previamente ser comunicado a SUNAT. Para ello
se utilizará la opción de “Actualización de certificado digital” habilitada en el
Menú SOL.
c) El certificado debe encontrarse vigente y no revocado, ya que el receptor de
SUNAT valida estos dos requisitos.

3.2

Consideraciones sobre el proceso de firmado
a) Para todos los documentos, la firma digital se consignará en un elemento
. Dentro de éste
elemento es donde se incluye la firma [XMLDSig] del emisor del documento. Por
tanto, en el documento únicamente habrá un solo para la
inclusión de la firma.
b) Se firmará todo el documento completo, es decir, todo el contenido del elemento
raíz: Invoice, CreditNote, DebitNote, SummaryDocuments o VoidedDocuments.
Se deberá utilizar el estándar de firmas XMLDSig.
c) Antes de firmar el documento, el archivo debe contener la totalidad de la
información del documento, incluyendo el elemento definido por
el estándar UBL con su respectiva información. Además se debe generar el
elemento donde se ubicará la firma digital.

Ejemplo de elemento antes de firmar:

~ 26 ~

SEE –Sistemas del Contribuyente Manual del programador

1001
348199.15

1000
CUATROCIENTOS VEINTITRES Y 00/100

d) La firma digital se debe alojar en el elemento creado
para tal fin.
e) Para firmar un documento electrónico se utilizará la clave privada de un
certificado digital X509. Luego de este proceso no podrán añadirse nuevos datos
al documento, ni siquiera extensiones en el formato acordado, puesto que la
validación consideraría que el documento ha sido alterado.
f)

La firma deberá generarse con el mismo tipo de codificación con el cual se
generó el documento xml. Por ejemplo, si el archivo xml a firmar es generado
con el ISO-8859-1, la firma también deberá ser generada con dicha codificación.

g) Mayores detalles de la firma digital se encuentra en cada informe de definición
de los documentos electrónicos y también puede ser revisado en la página web
del Consorcio World Wide Web - W3C (http://www.w3.org/TR/xmldsig-core/).

~ 27 ~

SEE –Sistemas del Contribuyente Manual del programador

4
4.1

Procedimientos específicos
Manejo de errores
El sistema realiza una serie de validaciones durante el proceso de recepción de
los documentos electrónicos. Cada una de estas validaciones en caso de no
cumplirse genera un tipo de error. Estos tipos son:
1. Excepciones:
Son errores graves que imposibilitan el procesamiento del archivo. En estos
casos, el documento se considera como no informado, y el emisor deberá
corregir el problema para volver a enviar el documento.
2. Errores que generan rechazos:
En estos casos se procesó el documento electrónico, pero se detectaron errores
que no permiten registrarlo como documento válido. Las implicancias de este tipo
de error dependen del tipo de documento procesado y son las siguientes:


En Facturas y Notas de crédito y débito asociadas:
Para estos documentos, la numeración se considera ya utilizada, pero la
factura o nota electrónicano es válida. En estos casos el emisor ya no
podrá utilizar ese número, y tendrá que generar un nuevo documento
corrigiendo el problema que generó el error y asignar un nuevo número al
documento.



En Retenciones, Percepciones y Guías de Remisión:
Para estos documentos, se rechaza el documento completo. No hay
procesamiento parcial, y tampoco se invalidan los números. Todo el
documento completo se considera como no informado.
El emisor debe corregir el problema y volver a enviar todo el documento
nuevamente.
Puede utilizar el mismo nombre de archivo.



En Resúmenes diarios de Boletas de Venta, Comunicación de baja,
Resumen de Reversiones:



En estos documentos donde se informa más de un número de
comprobante, se rechaza todo el documento completo. No hay
procesamiento parcial, y tampoco se invalidan los números. Todo el
documento completo se considera como no informado.
El emisor debe corregir el problema y volver a enviar todo el documento
nuevamente.
Puede utilizar el mismo nombre de archivo.
Lotes de facturas, notas de crédito y notas de débitos electrónicos:
En estos documentos donde se informa más de un número de
comprobante, cada documento cumple sus validaciones segúnel tipo de
documento.

~ 28 ~

SEE –Sistemas del Contribuyente Manual del programador

3. Observaciones
Son errores que no invalidan el documento y por lo tanto el sistema registrará el
comprobante como válido. Las observaciones se informarán en la Constancia de
Recepción.
La relación de los códigos de error y su descripción se encuentra en el parámetro
742. Los códigos se han clasificado de acuerdo al tipo de error:
- Del 0100 al 999 Excepciones propias de SUNAT.
- Del 1000 al 1999 Excepciones (formatos y estructura)propias del
contribuyente.
- Del 2000 al 3999 Errores que generan rechazo
- Del 4000 en adelante Observaciones

De acuerdo al tipo de error que se genera, el sistema responde de manera
distinta al emisor. Las respuestas son:
- Si es una EXCEPCION, el sistema responde como una excepción del
programa, es decir, retorna el código de error con su descripción.

4.2

Si hay un ERROR QUE GENERA RECHAZO, el sistema genera una
constancia de recepción (CDR)con estado rechazada, indicando que el
comprobante no ha sido registrado en SUNAT por tener errores.

Si hay OBSERVACIONES, el sistema genera una constancia de recepción
(CDR)con estado aceptada con advertencias, indicando que el comprobante
ha sido correctamente enviado y registrado en SUNAT. Las advertencias se
muestran en la constancia de recepción.

Finalmente, si no hay ningún tipo de error, se genera una constancia de
recepción (CDR) aceptada, indicando que el comprobante ha sido
correctamente enviado y registrado en SUNAT.

Utilización de campos del estándar UBL
El estándar UBL permite consignar una gran cantidad de datos comerciales.
Todos los elementos disponibles en la versión 2.0 de UBL pueden ser utilizados
por el emisor, siempre que cumplan con el formato establecido por el estándar.
La comprobación del cumplimiento del estándar se realiza verificando que el
documento cumple con el esquema (archivos con extensión xsd) que define su
estructura. Este proceso denominado “parseo” en el ámbito informático, debería
realizarse siempre luego de construido un documento electrónico y antes de
realizar su envío a SUNAT. Los diferentes lenguajes de programación ofrecen
librerías que permiten realizar esta verificación.

~ 29 ~

SEE –Sistemas del Contribuyente Manual del programador

4.3

PROCESO DE CONTINGENCIA
Se ha definido que los contribuyentes obligados al uso del comprobante de pago
electrónico, tengan la posibilidad de emitir comprobantes impresos por imprenta
autorizada, en aquellas situaciones en las cuales, por causas no imputables al
emisor, éste se vea imposibilitado de emitirlos por medios electrónicos. En tal
sentido, si ello ocurre, dicho emisor deberá cumplir con el envío de dicha
información a través la opción habilitada para tal efecto en SUNAT Operación en
Línea del portal de la SUNAT, según se indica a continuación:

4.3.1 Factura, boleta de venta, notas de crédito y débito y tickets
a) Condiciones de envío.
Para poder utilizar este procedimiento el contribuyente debe estar registrado como emisor
electrónico obligado.
Los comprobantes de pago a ser informados son aquellos impresos o importados por
imprenta autorizada y tickets o cintas emitidas por maquinas registradoras. En caso de
comprobantes impresos por imprenta autorizada, deberán corresponder a rangos
previamente autorizados por SUNAT
b) Procedimiento de envío
El envío del archivo resumen de comprobantes impresos, lo realiza el emisor electrónico
obligado utilizando la opción correspondiente habilitada en SUNAT Operaciones en Linea.
Para realizar el envio se deberá realizar lo siguiente:
Paso 1: Preparar un archivo de extensión “TXT” conteniendo la información de los
comprobantes, en ninguno de los casos se incluye el detalle o descripción de los ítems
del comprobante.
Las especificaciones de cada campo de este RESUMEN está descrito en el ANEXO 11
RESUMEN DE COMPROBANTES IMPRESOS
Luego de completar la longitud de cada campo se debe incluir un símbolo conocido como
pipa o palote “|”.
El registro de los comprobantes debe completarse de la siguiente forma:
—
—
—
—
—
—
—

Facturas: Se prepara la información de la factura una por línea.
Boletas: Se prepara la información de la boleta una por línea.
Notas de crédito (Relacionadas con Facturas y Boletas): Se prepara una por línea.
Notas de debito (Relacionadas con Facturas y Boletas): Se prepara una por línea.
Tickets que otorguen derecho a crédito fiscal: se preparan de uno por línea.
Tickets que no otorguen derecho a crédito fiscal: se prepara como resumen.
Boleto de viaje emitido por las empresas de transporte público interprovincial de
pasajeros: Se prepara uno por línea

Una vez elaborado el archivo deberá ser guardado con extensión. “txt.”. Para
efecto del nombre del archivo deberá considerar lo indicado en el punto 6.4.6
Paso 2: Comprimir el archivo TXT en otro de extensión “ZIP” .
Paso 3: Cargue en archivo .ZIP, recibirá un número de constancia generada por SUNAT
operaciones en Linea ( “ticket”)
~ 30 ~

SEE –Sistemas del Contribuyente Manual del programador
c) Procedimiento de envío por correcciones
En caso se requiera corregir un envío realizado, se deberá elaborar nuevamente el archivo
Resumen de Comprobantes Impresos como si se tratase del original.
El último archivo RESUMEN enviado reemplazará por completo al anterior,
d) Procesamiento de envíos
Los envíos son procesados secuencialmente, al momento de su recepción.
En caso de existir errores, éstos serán puestos a disposición en la opción correspondiente
de SUNAT Operacioens en Linea (Opción consultas) . A través de esta opción, se activará
un link de descarga de archivo de errores.
Los envíos sin errores será cargados como comprobantes de pago, notas de crédito y/o
notas de débito informados por contingencia
e) Seguimiento de envíos
Los contribuyentes pueden hacer consultas de sus envíos utilizando la opcion
correspondiente habilitada en SUNAT Operaciones en Línea, por número de constancia
generada por SUNAT Operaciones en línea (“ticket”) o rangos de fechas.
f)

Estructura del Nombre del Archivo – Comprobantes Impresos
El nombre de los archivos está en función a la fecha a la que corresponde el envío.
El nombre del archivo debe cumplir con el formato

"99999999999-RF-DDMMYYYY-99" donde:
‒
‒
‒
‒

99999999999 números de ruc
RF: Caracteres identificativos del archivo "RF" textualmente
representa resumen de facturas.
DDMMYYYY: Fecha de emisión en contingencia en formato
"DDMMYYYY”; ejemplo 15072014.
99: Numero de envío dato entre 01 al 99.

Las extensiones del archivo son .TXT y .ZIP según corresponda.

4.3.2

Comprobantes de Retención y Percepción
Resumen diario de comprobantes de percepción/retención emitidos en
formatos impresos (contingencia)
Posición
01-11
12
13-14

Nemotécnico
RRRRRRRRRRR
TT
40
41

Descripción
RUC del emisor electrónico
Guión separador
Tipo de comprobante
Comprobante de Percepción
Comprobante de Percepción Venta
~ 31 ~

SEE –Sistemas del Contribuyente Manual del programador
Interna
Comprobante de Retención
15
Guión separador
16-23
Fecha de la generación del archivo en
formato YYYYMMDD
24
Guión separador
25-29
CCCCC
Número correlativo del archivo. Este
campo es variante, se espera un
mínimo de 1 y máximo de 5.
30 (*)
.
Punto de extension
31-33 (*)
EEE
Extensión del archive
TXT
Para el caso del formato TXT
ZIP
Para el caso del archivo ZIP
(*) Las posiciones pueden variar dependiendo de la longitud del correlativo.
20
YYYYMMDD

Ejemplo:
Nombre del archivo ZIP: 20100066603-40-20150522-1.ZIP
Nombre del archivo XML: 20100066603-40-20150522-1.TXT

Los comprobantes a ser informados son aquellos emitidos en formatos impresos
por imprenta autorizada, cuyos rangos han sido previamente autorizados por la
SUNAT.



Procedimiento de envío

El envio del archivo Resumen diario de comprobantes de percepción/retención
emitidos en formatos impresos lo realiza el emisor electrónico utilizando la
opción correspondiente habilitada en SUNAT Operaciones en Línea.
Para realizar el envío se deberá realizar lo siguiente:


Paso 1: Preparar un archivo de extensión “TXT” conteniendo la información
de los comprobantes y sus documentos relacionados,
Las especificaciones de cada campo de este RESUMEN están descritos en
los Anexos 19 y 20. Luego de completar la longitud de cada campo se debe
incluir un símbolo conocido como pipa o palote “|”.
Una vez elaborado el archivo deberá ser guardado con extensión.
“txt.”. Para efecto del nombre del archivo deberá considerar lo
indicado en el punto “Estructura del nombre del archivo”

 Paso 2: Comprimir el archivo TXT en otro de extensión “ZIP”
 Paso 3: Cargue el archivo .ZIP, recibirá un número de constancia generada
por SUNAT operaciones en Linea ( “ticket”)



Procedimiento de envío por correcciones

En caso se requiera corregir un envío realizado, se deberá elaborar nuevamente
el archivo RESUMEN como si se tratase del original. El ultimo archivo
RESUMEN enviado reemplazará por completo al anterior.



Procesamiento de envíos

~ 32 ~

SEE –Sistemas del Contribuyente Manual del programador
Los envíos son procesados secuencialmente, al momento de su recepción. En
caso de existir errores, éstos serán puestos a disposición en la opción
correspondiente de SUNAT Operaciones en Línea (Opción consultas). A través
de esta opción, se activará un link de descarga de archivo de errores.



Seguimiento de envíos

Los contribuyentes pueden hacer consultas de sus envíos utilizando la opcion
correspondiente habilitada en SUNAT Operaciones en Línea, por número de
constancia generada por SUNAT Operaciones en línea (“ticket”) o rangos de
fechas.



Estructura del Nombre del Archivo - Contingencia

El nombre de los archivos está en función a la fecha a la que corresponde el
envío.
El nombre del archivo debe cumplir con lo indicado en el literal e).

"RRRRRRRRRRR-TT-20150522-1" donde:
‒
‒

‒
‒

RRRRRRRRRRR: RUC del emisor electrónico
TT: Tipo de comprobante, pueden ser:
o 40 Comprobante de Percepción.
o 41 Comprobante de Percepción Venta Interna.
o 20 Comprobante de Retención.
YYYYMMDD: Fecha de emisión en contingencia en formato
"YYYYMMDD”
1: Número correlativo del archivo. Este campo es variante, se espera
un mínimo de 1 y máximo de 5.

Las extensiones del archivo son .TXT y .ZIP según corresponda.

~ 33 ~

SEE –Sistemas del Contribuyente Manual del programador

ANEXO 1: Constancia de Recepción
La Constancia de Recepción es el documento que permitirá indicar la respuesta de la
aplicación SUNAT a la transacción de recepción de la factura, nota o resúmenes
enviados por el contribuyente. Este documento informará el estado de recepción,
indicando si ha sido aceptado o rechazado por SUNAT.
El objetivo de este anexo es describir las normas de uso que usará SUNAT cuando
construya el documento de respuesta al proceso de recepción de documentos
electrónicos. Este documento está basado en el esquema del documento
ApplicationResponse del estándar UBL versión 2.0.
A. Información contenida en la Constancia de Recepción y estructura XML
Los diferentes campos contenidos en la constancia de recepción se detallan en el
cuadro del literal A.1.
Para elaborar dicho cuadro se ha tomado en cuenta la siguiente nomenclatura:
 Para los tipos de campos y longitud:
a
n
an
a3
n3
an3
a..3
n..3
an..3

caracter alfabético
caracter numérico
caracter alfanumérico
3 caracteres alfabéticos de longitud fija
3 caracteres numéricos de longitud fija
3 caracteres alfa-numéricos de longitud fija
hasta 3 caracteres alfabéticos
hasta 3 caracteres numéricos
hasta 3 caracteres alfa-numéricos

 Para la condición de obligatoriedad o no de un determinado elemento:
M: Mandatorio u obligatorio
C: Condicional u opcional
 En lo referente a la identificación del formato de los elementos:
n(12,2)
n(2,2)
F#####
YYYY-MM-DD

elemento numérico hasta12 enteros + punto decimal+ hasta
dos decimales
elemento numérico hasta 2 enteros + punto decimal+ hasta dos
decimales
elemento inicia con la letra F seguida de cinco dígitos
formato fecha yyyy=año, mm=mes, dd=día

En el cuadro del literal A.2 se muestra la estructura del documento ApplicationResponse
de acuerdo a UBL versión 2.0 y una referencia a la información que estará contenida en
cada elemento. Además se muestra la cardinalidad de acuerdo al UBL y el asumido
para el caso peruano

~ 34 ~

SEE –Sistemas del Contribuyente Manual del programador

A.1 Campos contenidos en la Constancia de Recepción

N°

CAMPOS

1
2
3
4
5
6
7
8
9
10

Firma Digital (Firma electrónica)
Número identificador del proceso de recepción
Fecha derecepcióndel documento electrónico procesado
Horaderecepcióndel documento electrónico procesado
Fecha de generación de la constancia de recepción
Horade generación de la constancia de recepción
Mensajes o notas asociados a la constancia de recepción
Número de RUC del Emisor delaconstancia
Número de RUC del Receptor de la constancia
Identificador del documento electrónico enviado

Global
Global
Global
Global
Global
Global
Global
Global
Global
Global

M
M
M
M
M
M
M
M
M
M

an..3000
n15
an..10
an..11
an..10
an..11
an..100
n11
n11
an..23

11
12
13

Código de respuesta del envío
Descripción de la respuesta del envío
Identificador del documento electrónico procesado

Global
Global
Global

M
M
M

n..4
an..100
an..23

Identificación del receptor del documento electrónico
procesado
Versión del UBL
Versión dela estructura del documento

Global

an..13

Global
Global

M
M

an..10
an..10

15
16

NIVEL

CONDICIÓN

TIPO Y LONGITUD

FORMATO

YYYY###########
YYYY-MM-DD
hh:mm:ss
YYYY-MM-DD
hh:mm:ss

OBSERVACIONES

Formato Date del XML
Formato Date del XML

Formato de acuerdo al tipo de documento
procesado

~ 35 ~

SEE –Sistemas del Contribuyente Manual del programador

A.2 Estructura XML de ApplicationResponse según norma UBL

ESTRUCTURA XML APPLICATIONRESPONSE - PERU
Etiqueta XML
ApplicationResponse

./ext:UBLExtensions
./ext:UBLExtension/ext:ExtensionContent
./ds:Signature @Id
./ds:SignedInfo
./ds:CanonicalizationMethod@Algorithm
./ds:SignatureMethod@Algorithm
./ds:Reference@URI
./ds:Reference/ds:Transforms/ds:Transform@Algorithm
./ds:Reference/ds:DigestMethod@Algorithm
./ds:Reference/ds:DigestValue
./ds:SignatureValue
./ds:KeyInfo/ds:X509Data/ds:X509Certificate
./cbc:UBLVersionID
.cbc:CustomizationID
./cbc:ID

Descripción
Documento para indicar la respuesta de SUNAT al proceso de recepción
de documentos
Contenedor de Componentes de extensión. Podrán incorporarse nuevas
definiciones estructuradas cuando sean de interés conjunto para
emisores y receptores, y no estén ya definidas en el esquema del
documento de respuesta.
Componente de extensión para especificar la firma XMLDSIG
Identificaciónde la firma dentro del documento
información sobre el valor de la firma e información sobre los datos a
firmar
Indica cómo se debe transformar a forma canónica el elemento
antes de realizar la firma
Especifica qué tipo de algoritmo de firma que se utilizará para obtener la
firma
Identifica al objeto de datos que se va a firmar, Si su valor es cadena
vacía identifica al documento completo que contiene la firma
Indica un paso realizado en el procesamiento de cálculo del hash.
Define la función hash utilizada
Es el valor hash codificado en Base64
Contiene la firma codificada en Base64
Es una estructura que contiene información del certificado firmante
Versión de UBL
Versión dela estructura del documento
Número único asignado por SUNAT para identificar el proceso de
recepción

Cardinalidad Constancia de
UBL
Recepción

0..1
1..n
1

1
1
1

1..n
1..n
0..n
1
1
1..n

1
1
1
1
1
1

0..1
0..1

1
1

~ 36 ~

SEE –Sistemas del Contribuyente Manual del programador

./cbc:IssueDate
./cbc:IssueTime
./cbc:ResponseDate
./cbc:ResponseTime
./cbc:Note
./cac:Signature
./cbc:ID
./cac:SignatoryParty
./cac:PartyIdentification

Fecha de recepción del documento procesado (yyyy-mm-dd)
Hora de recepción del documento procesado (hh:mm:ss.OZ)
Fecha de generación de la constancia de recepción (yyyy-mm-dd)
Hora de generación de la constancia de recepción (hh:mm:ss.OZ)
Mensajes o notas asociados al documento de respuesta
Referencia a la Firma Digital
Identificador de la firma
Parte firmante

1
0..1
0..1
0..1
0..n
0..n
1
1
0..n

1
1
1
1
0..n
1
1
1
1

./cbc:ID

Identificación de la parte firmante

0..n

./cac:PartyName
./cbc:Name

Nombre de la parte firmante

./cac:DigitalSignatureAttachment

Asociación con la firma codificada (en formato XMLDSIG, por ejemplo)

0..1

./cac:ExternalReference

Información acerca de un documento vinculado.
Identificador de Recurso Uniforme (o URI) que identifica la localización
de la firma

0..1

Información sobre la parte que remite la información.
Describe el tipo de documento de identificación a la parte que remite la
información
Indica el número de identificación (RUC) de la parte que envía la
información (SUNAT)

1..n
1

1
1

Información sobre la parte que recibe la información
Describe el tipo de documento de identificación a la parte que recibe la
información
Indica el número de identificación (RUC) de la parte que recibe la
información.

1..n
1

1
1

./cbc:URI

./cac:SenderParty
./cac:PartyIdentification
./cbc:ID

./cac:ReceiverParty
./cac:PartyIdentification
./cbc:ID

~ 37 ~

SEE –Sistemas del Contribuyente Manual del programador

./cac:DocumentResponse
./cac:Response
./cbc:ReferenceID
./cbc:ResponseCode
./cbc:Description

Describe el estado de la constancia de recepción
Información sobre la respuesta al proceso de recepción
Identificación del documento electrónico procesado
Código de la respuesta al documento electrónico procesado
Descripción de la respuesta al documento electrónico procesado

1..n
1..n
1..n
1..n
1..n

1
1
1
1
1

./cac:DocumentReference
./cbc:ID

Identificación del documento procesado
Identificador del documento electrónico procesado

1..n
1

1
1

./cac:RecipientParty

Información dela parte receptora del documento electrónico procesado

1..n

./cac:PartyIdentification

Identificación dela parte receptora del documento electrónico procesado

./cbc:ID

Identificación del receptor del documento electrónico procesado

~ 38 ~

SEE –Sistemas del Contribuyente Manual del programador

Elementos de la Constancia de Recepción

Para un mejor entendimiento de la estructura del archivo XML, se muestra el diagrama
respectivo en donde se muestra los elementos utilizados para la constancia de
recepción.

A continuación se detallan los elementos que forman parte de la constancia de
recepción. En cada uno de ellos se indica una explicación de la información que
almacena:
B.1 ext:UBLExtensions
Contenedor de Componentes de extensión. Para el caso peruano se utilizará para
consignar la información correspondiente a la firma digital.

~ 39 ~

SEE –Sistemas del Contribuyente Manual del programador



ds:Signature: Este elemento complejo se ubicará dentro del tag
y contendrá la información correspondiente a la firma
digital, la cual se encontrará estructurada de acuerdo a las especificaciones de
XMLDSig (recomendación de W3C para firmas digitales).

B.2 cbc:UBLVersionID
Versión del esquema UBL utilizado para la elaboración de la constancia de recepción.
Para el caso peruano se ha utilizado la versión “2.0”.
2.0

B.3 cbc:CustomizationID
Identifica una personalización de UBL definida para un uso específico. Para nuestro
caso corresponderá a la versión 1.0. Por cada variación o adecuación del esquema se
deberá de aumentar la versión.
1.0

B.4 cbc:ID
Número único asignado por SUNAT para identificar el proceso de recepción.

B.5 cbc:IssueDate
Fecha de recepción del documento electrónico enviado por el contribuyente. El tipo de
dato corresponde con el tipo Date de XML por lo que el formato deberá ser yyyy-mmdd.
2012-06-01

B.6 cbc:IssueTime
Hora de recepción del documento electrónico enviado por el contribuyente. El
documento puede ser un comprobante de pago, nota electrónica, resumen diario o

~ 40 ~

SEE –Sistemas del Contribuyente Manual del programador

comunicación de baja. El tipo de dato corresponde con el tipo Time de XML por lo que
el formato deberá ser hh:mm:ss.
15:12:23
B.7 cbc:ResponseDate
Fecha de generación de la constancia de recepción. El tipo de dato corresponde con el
tipo Date de XML por lo que el formato deberá ser yyyy-mm-dd.
2012-06-01

B.8 cbc:ResponseTime
Hora de generación de la constancia de recepción. El tipo de dato corresponde con el
tipo Time de XML por lo que el formato deberá ser hh:mm:ss.
15:13:00

B.9 cac:Signature
Utilizado para identificar al firmante y otro tipo de información relacionada con la firma
digital. Su uso se da principalmente para especificar la ubicación de la firma digital.




cbc:ID. Identificador de la firma.
cac:SignatoryParty. Asociación con la parte firmante, la cual para el
caso de la constancia de recepción corresponde a los datos de SUNAT.
o PartyIdentification. A través del elemento ID, se consigna el RUC
de la parte firmante.
o PartyName. A través del elemento Name, se consigna el nombre de
la parte firmante. En este caso corresponde a SUNAT.



cac:DigitalSignatureAttachment. En este componente se puede
referenciar la firma del documento como una referencia externa a una
URI local o remota.

~ 41 ~

SEE –Sistemas del Contribuyente Manual del programador

B.10

ExternalReference. Información acerca de un documento
vinculado. Los vínculos pueden ser externos (referenciados
mediante un elemento URI), internos (accesibles mediante un
elemento MIME) o pueden estar contenidos dentro del mismo
documento en el que se alude a ellos (mediante elementos
Documento Incrustado). Este último será el caso a utilizar, es
decir una referencia dentro del mismo documento
ApplicationResponse.Específicamente se referencia hacia el
componente UBLExtensionsdonde se ha colocado la firma
digital.

cbc:Note

Los mensajes o notas almacenados en este elemento, corresponderán a advertencias
sobre inconsistencias detectadas en el proceso de recepción del documento
electrónico, pero que no representan rechazos. Estos mensajes se consignarán con el
siguiente formato:
-
4001-Número de RUC del receptor no existe
4031-Debe indicar el nombre comercial

B.11 cac: SenderParty
Información sobre la parte que remite la información.



PartyIdentification. En este elemento se consigna los datos de
identificación de la parte emisora de la constancia de recepción. En este
caso corresponde a datos de SUNAT.

cbc:ID. Indica el Número de RUC del emisor de la
constancia de recepción (RUC de SUNAT).
~ 42 ~

SEE –Sistemas del Contribuyente Manual del programador

20131312955

B.12 cac: ReceiverParty
Información sobre la parte que recibe la constancia de recepción.



PartyIdentification. En este elemento se consigna los datos de
identificación de la parte que recibe la constancia de recepción. En este
caso corresponde a datos del emisor del documento electrónico enviado a
SUNAT.

cbc:ID.Indica el Número de RUC del receptor de la constancia
de recepción.

Un ejemplo de ReceiverParty, sería:

20100043218

B.13 cac: DocumentResponse
Información sobre la respuesta que se da al proceso de recepción del documento
electrónico enviado por el contribuyente.

~ 43 ~

SEE –Sistemas del Contribuyente Manual del programador



Response:Respuesta al documento recibido.

cbc:ReferenceID. Identificador del documento enviado por el
contribuyente.
o
o

Para el caso de facturas, notas de crédito y notas de
débito se consignará la serie y número de documento
separado por un guión: -
Para el caso de resúmenes diarios y comunicaciones de
baja, se colocará el nombre del archivo de acuerdo al
siguiente formato:
--
--



cbc:ResponseCode. Proporciona el código que da respuesta al
proceso de recepción. Indica el estado de la recepción del
documento enviado por el contribuyente:
o Si es Aceptada se colocará el valor cero (“0”).
o Si es Rechazada se colocará un valor diferente de cero, y
que corresponde al código del error que genera el
rechazo.

cbc:Description. Describe la respuesta que se da al
documento. En el caso de estado aceptado, se muestra una
descripción indicando dicha situación. En caso de estado
rechazado, se muestra la descripción del error que generó el
rechazo.

DocumentReference: En este elemento se ubicará la identificación del
documento electrónico procesado.
~ 44 ~

SEE –Sistemas del Contribuyente Manual del programador



cbc:ID. Identificador del documento electrónico procesado.
o Si el documento es un comprobante de pago o nota, se
consignará la serie y número de comprobante.
o Si el documento es un resumen diario o una
comunicación de baja, se consignará el nombre del
archivo.

RecipientParty: En este elemento se ubicará la identificación del receptor
del documento electrónico procesado.

PartyIdentification. A través del elemento ID, se consigna la
identificación de la parte receptora el documento electrónico
procesado.
o

cbc:ID. Indica el tipo y número de documento de
identidad del receptor del documento electrónico
procesado.
Para la factura y notas, corresponde a los datos del
adquiriente o usuario. Los datos se encontrarán
separados por un guión:
-
Para el caso del resumen diario y la comunicación de
baja, se consignará un guión.

~ 45 ~

SEE –Sistemas del Contribuyente Manual del programador
Ejemplo:

F001-747
0
La factura numero F001-747, ha sido aceptada

F001-747

06-20100088982

~ 46 ~

SEE –Sistemas del Contribuyente Manual del programador

C.
C.1

Ejemplos
Respuesta de aplicación SUNAT – Estado ACEPTADO
REQUISITO

Número identificador del proceso de recepción
Fecha de recepción del documento electrónico procesado
Hora de recepción del documento electrónico procesado
Fecha de generación del documento de respuesta
Hora de generación del documento de respuesta
Mensajes o notas asociados al documento de respuesta

Número de RUC del Emisor de la constancia de recepción (SUNAT)
Número de RUC del Emisor del documento electrónico procesado
Número de RUC del Receptor del documento electrónico
procesado
Identificador del documento enviado
Código de respuesta del envío
Descripción de la respuesta del envío
Identificador del documento procesado

CASO 1

201200000230061
2012-06-12
10:09:27
2012-06-12
10:09:30
4031 - Debe indicar el nombre comercial
4001 - El numero de RUC del receptor no
existe
20131312955
20150147718
20997898754
FA01-981
0
La Factura numero FA01-981, ha sido
aceptada
FA01-981

Firma Digital

2Hp6yx1+sD9H6n0hDMC625+I40U=

32xhlEkXaoaTKAhxiIdf13qXNGFhcIPROd8dSZpFRqgr8em43vXl4Is/I+mMhTgn9o
Agg5CxpVfa
AExM5JJxp9laI+YC4QUKJ8jyIurMCxk2SngUnV5tfrp/ydy/y4bASVDuNp+ewNIUVhXEUQA9sLs+
JnWYj0WPlppqykHm5W8=

MIIC3TCCAcUCCQCbWZdbGxwQajANBgkqhkiG9w0BAQUFADCBhzELMAkGA1UEBhMCU
EUxDTALBgNV
BAgTBExpbWExDTALBgNVBAcTBExpbWExDjAMBgNVBAoTBVNVTkFUMQ0wCwYDVQQLEwRERFNUMRYw
FAYDVQQDEw1Kb2hubnkgVmFsZGV6MSMwIQYJKoZIhvcNAQkBFhRqdmFsZGV6QHN1bmF0LmdvYi5w
ZTAeFw0wODA3MTYxNzE2MDdaFw0xNDAxMDYxNzE2MDdaMF0xCzAJBgNVBAYTAlBFMQ0wCwYDVQQI
EwRMaW1hMQ0wCwYDVQQHEwRMaW1hMQ4wDAYDVQQKEwVTVU5BVDENMAsGA1UECxMERERTVDERMA8G
A1UEAxMIc3J2ZGVzYTEwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOP4nN062737OUzejMiH
p5hba8/IbAfvyedc7aTXWpf6MHXpxT7X6qVoUSG2ulmKygkPW2h8ogyZC9RLo/SBIoGZrt5bD+Cm
1dsK3H4ObRgLDlK6ftdIVZFkvr6rYXGiz92je0QNaNVXuktsNskmvGUbMG6bcUSypQB4rDZhgR9r
AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBALN/qz38GM4H4M8T7uPXEqPGurSqfUT59KYqoZ/R24Kf
aI/t44usI0QbNJSp8w9Yl01XyO+ewnBzJNOKJtL3M8LiawjRoz0DSa8uPJQEMgQXvgJeipAe+IO7
yLMiYA3rOaG1nSXcBYUaRTh6AGeWW+pIheThhcq+Z7uHXMoqbBkIzpUuflkZKPAZFFkSQTUYyhrB
Bv1Vj8nEfoy+y9758KTc7n6yF3GJOIUUpzDQJ65iaIrL6CIlbyHHPhNIcrS2iDvYskqjamiI4Qzs
Kcm+qcFRf7UZWYNPCA9w9QISByv5KqVfDQtgZGRh3Uved9BR15mpbdVvs9tJhLYrTHw7Fb8=

2.0
1.0
201200000230061
2012-06-12
10:09:27
2012-06-12
10:09:30
4031 - Debe indicar el nombre comercial
4001 - El numero de RUC del receptor no existe.

SignSUNAT

20131312955

#SignSUNAT

20131312955

20150147718

FA01-981
0

FA01-981

6-20997898754

~ 48 ~

SEE –Sistemas del Contribuyente Manual del programador

C.2

Respuesta de aplicación SUNAT – Estado RECHAZADO

REQUISITO
Número identificador del proceso de recepción
Fecha de recepción del documento electrónico procesado
Hora de recepción del documento electrónico procesado
Fecha de generación del documento de respuesta
Hora de generación del documento de respuesta
Mensajes o notas asociados al documento de respuesta
Número de RUC del Emisor de la constancia de recepción
(SUNAT)
Número de RUC del Emisor del documento electrónico
procesado
Número de RUC del Receptor del documento electrónico
procesado
Identificador del documento enviado
Código de respuesta del envío
Descripción de la respuesta del envío

Identificador del documento procesado

CASO 2
201200000230098
2012-06-13
13:20:37
2012-06-13
13:21:38
20131312955
20150147718
20196582743
FT01-982
2047
Es obligatorio al menos un
AdditionalMonetaryTotal con codigo 1001,
1002 o 1003
FA01-981

Firma Digital

urbmyAumKx6HkJbT8fvUIJxzV+c=

GnHp455UMFKgplGx7urhV3G1XHGg0loKPsnj4fDgy1byNd93lzVtkIKQXOJtSQVJ3t
mss94dzxl0
Yf3gKfLt01M4QCNOuyTnRNdvwl9pjjzKUbN3H8Tsb3BAX91NvzNlgUhbw7dxJgGeWJkTfihEZGPT
/02COVKdDwrBPBWp2zU=

~ 49 ~

SEE –Sistemas del Contribuyente Manual del programador

Bv1Vj8nEfoy+y9758KTc7n6yF3GJOIUUpzDQJ65iaIrL6CIlbyHHPhNIcrS2iDvYskqjamiI4Qzs
Kcm+qcFRf7UZWYNPCA9w9QISByv5KqVfDQtgZGRh3Uved9BR15mpbdVvs9tJhLYrTHw7Fb8=

2.0
1.0
201200000230098
2012-06-13
13:20:37
2012-06-13
13:21:38

SignSUNAT

20131312955

#SignSUNAT

20131312955

20150147718

FT01-982
2047

FT01-982

6-20196582743

~ 50 ~

SEE –Sistemas del Contribuyente Manual del programador

C.3

Respuesta de aplicación SUNAT – Excepción en producción.

soap-env:Server.0835

descripción del error

El indicador faultcode, nos puede indicar:
-

Server: es probable que el problema (causante de la excepción) se encuentre por
el servidor de SUNAT.

Client: es probable que el problema se encuentre en la parte del cliente. Por
ejemplo el archivo está mal formado.

~ 51 ~

SEE –Sistemas del Contribuyente Manual del programador

ANEXO 2: SERVICIO WEB CONSULTA DE FACTURAS Y NOTAS
1. La consulta es un servicio web
2. Esta versión sólo permite consultar facturas y notas de crédito y debito, que
inicien con “F”
3. Para utilizar esta consulta, se tiene que construir un cliente que se conecte al
servicio web.
La URL del servicio web es la siguiente:
https://www.sunat.gob.pe/ol-it-wsconscpegem/billConsultService
4. El cliente envía una petición al servidor en formato XML; un ejemplo de esta
petición es:

20100066603MODDATOS
moddatos

1028308796
01
f213
12345

Donde:
~ 52 ~

SEE –Sistemas del Contribuyente Manual del programador

20100066603MODDATOS
20100066603MODDATOS = RUC contribuyente más usuario sol.

moddatos
moddatos =clave sol del contribuyente

1028308796
1028308796 = RUC del comprobante que se quiere consultar

01
01 = tipo de comprobante que se quiere consultar (01:factura, 07: nota de
crédito y 08:nota de debito)

f213
f213 = número de serie del comprobante que se quiere consultar

12345
12345 = número del comprobante que se quiere consultar

5. La consulta es solo del estado del documento electrónico.
Ejemplo del XML de retorno del servidor.

Donde
-

0001
0001 = código de retorno

El comprobante existe y está aceptado.
El comprobante existe y está aceptado. = descripción del mensaje.

6. Posibles valores de retorno en la siguiente tabla.

~ 53 ~

SEE –Sistemas del Contribuyente Manual del programador

TIPO

CODIGO

DESCRIPCION RETORNO

RETORNO
EXITO

0001

El comprobante existe y está aceptado.

EXITO

0002

El comprobante existe pero está rechazado.

EXITO

0003

El comprobante existe pero está de baja.

ERROR

0004

Formato de RUC no es válido (debe de contener
11 caracteres numéricos).

ERROR

0005

Formato del tipo de comprobante no es válido
(debe de contener 2 caracteres).

ERROR

0006

Formato de serie inválido (debe de contener 4
caracteres).

ERROR

0007

El numero de comprobante debe de ser mayor
que cero.

ERROR

0008

El número de RUC no está inscrito en los
registros de la SUNAT.

ERROR

0009

EL tipo de comprobante debe de ser (01, 07 o
08).

ERROR

0010

Sólo se puede consultar facturas, notas de crédito
y debito electrónicas, cuya serie empieza con "F"

ERROR

0011

El comprobante de pago electrónico no existe.

ERROR

0012

El comprobante de pago electrónico no le
pertenece.

~ 54 ~

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.4
Linearized                      : No
Page Count                      : 54
Language                        : es-PE
Tagged PDF                      : Yes
XMP Toolkit                     : 3.1-701
Producer                        : Microsoft® Office Word 2007
Creator                         : prueba
Creator Tool                    : Microsoft® Office Word 2007
Create Date                     : 2016:09:22 16:50:04Z
Modify Date                     : 2016:09:22 16:50:04Z
Document ID                     : B4CCBE4E-2130-4D59-9773-1ABBA7BE94F3
Instance ID                     : B4CCBE4E-2130-4D59-9773-1ABBA7BE94F3
Part                            : 1
Conformance                     : B
Author                          : prueba

EXIF Metadata provided by EXIF.tools

Manual+de+Programador

Manual%2Bde%2BProgramador

Navigation menu

Versions of this User Manual:

Views

Navigation