Mensaje del Receptor para Factura Electrónica

En este artículo hablaremos del Mensaje del Receptor que esta establecido en la Resolución de Comprobantes Electrónicos; sus diferentes elementos y como se debe hacer uso del mismo.

¿Qué es el Mensaje del Receptor?

De acuerdo a la Resolución de Comprobantes Electrónicos DGT-R-48-2016 (versión 4.2), se establece que entre las obligaciones del receptor electrónico está:

Enviar a la Administración Tributaria los archivos XML de aceptación o rechazo de los comprobantes electrónicos para su respectiva validación.

Es decir, como receptores deberíamos enviar un mensaje de aceptación o rechazado para cada documento electrónico en el cual somos su receptor. Por ejemplo: la factura electrónica que nos envian por adquirir ‘x’ bien o servicio.

Pero; ¿qué es un mensaje de receptor?

Es un XML que se rige por un XML Schema ya establecido y publicado por el Ministerio de Hacienda.

Este XML esta conformado por varios componentes; que analizaremos seguidamente:

• Clave: Este atributo obligatorio de 50 posiciones corresponde a la clave del documento (sea una factura, tiquete, nota de débito o de crédito) al cual le estamos dando una respuesta.
• NumeroCedulaEmisor: Es un atributo obligatorio que corresponde al número de identificación del emisor del documento original que estamos respondiendo. No es la identificación del receptor.
• FechaEmisionDoc: Es un atributo obligatorio que corresponde a la fecha y hora en la cual se esta haciendo la emisión de esta respuesta. No es la fecha de emisión del documento que se responde.
• Mensaje: Es un atributo obligatorio de una posición que puede tener los siguientes valores: 1 (aceptado), 2 (aceptado parcialmente) y 3 (rechazado)

Es importante tomar en cuenta que significa el valor de aceptado parcialmente, y presentamos literalmente la definición del Ministerio de Hacienda:

Para uso exclusivo del Obligado Tributario permite aceptar de forma parcial el contenido de un comprobante electrónico, permitiendo con esto la confesión de una nota de crédito que permita ajustar la operación por el monto menor al de la factura originalmente emitida, de forma tal que la suma algebraica de sus importes, sea positivo el de la factura y negativo el de la nota de crédito, dando como resultado el valor neto real de la operación.

• DetalleMensaje: Es un atributo opcional de hasta 80 posiciones para consignar cualquier texto de relevancia que el receptor desee constar.
• MontoTotalImpuesto: Es un atributo condicional que se debe usar si y solo si, el documento que respondemos contaba con un detalle de impuesto. Si el documento que vamos a responder no tenía impuestos, no se debe colocar este atributo en el XML de respuesta. En caso de que lo coloquemos; el monto que se consigne debe ser el mismo que esta establecido en el documento. Caso contrario, se recibiría una advertencia por parte de la plataforma indicando que los montos no coinciden.
• TotalFactura: Es un atributo obligatorio que corresponde al monto total del documento al que estamos dando respuesta. Si el valor no coincide se recibiría una advertencia por parte de la plataforma indicando esa situación.
• NumeroCedulaReceptor: Es un atributo obligatorio en donde se coloca el número de identificación del receptor del documento. Evidentemente, debe ser la misma identificación del receptor que se colocó en el documento al que vamos a responder.
• NumConsecutivoReceptor: Este atributo obligatorio de 20 posiciones que corresponde al número consecutivo del receptor y cuya definición abarca de la página 5 a la 7 de la Resolución de Comprobantes Electrónicos DGT-R-48-2016. Y que seguidamente resumimos:
  • De la posición 1 a 3, se identifica el local o establecimiento desde se emitió el mensaje de receptor. El número 001 corresponde a la oficina central y del 002 en adelante a las sucursales.
  • De la posición 4 a la 8, identifica la terminal o punto de venta, inicia en 00001.
  • De la posición 9 al 10, corresponde al tipo de documento que estamos trabajando. En este caso, al ser un mensaje de receptor, debemos elegir entre 05 (aceptación), 06 (aceptación parcial) o 07 (rechazo). Es importante que haya una consistencia entre esos valores y el dato que coloquemos en el atributo Mensaje. Es decir, si en Mensaje colocamos el valor 1 de aceptación, entonces debemos colocar el valor 05 en este espacio. Caso contrario, se daría un rechazo por parte del Ministerio de Hacienda.
  • De la posición 11 a la 20, corresponde al consecutivo del receptor iniciando en 1 para cada terminal o sucursal.

Por supuesto, el XML que generemos debe ir firmado digitalmente por el receptor de acuerdo al estandar de XAdES-EPES.

¿Qué situaciones generarían un rechazo del mensaje del receptor?

Según nuestra experiencia, las causas que generan un rechazo de un mensaje de receptor son:

• Un documento firmado erróneamente.
• El NumConsecutivoReceptor esta mal formado o bien, no hay coincidencia entre el valor de la posición 9 a 10 y el dato que se dispuso en Mensaje.
• El NumeroCedulaEmisor no coincide con el emisor del documento que estamos respondiendo.
• Que traten de dar respuesta a un documento que nunca ha sido enviado a la plataforma de Hacienda.
• Que omitan el atributo MontoTotalImpuesto cuando el documento que responden si lo tiene presente.
• Que envien el atributo MontoTotalImpuesto cuando el documento que responden no tenía impuestos.

¿Qué pasa si quiero responder un documento y no estoy como receptor?

En este caso, no pueden enviar un mensaje de receptor si en el documento original no aparece registrado como receptor. Eso puede ser causado por error humano, por ejemplo que en la factura no registraron al receptor (omitieron el nodo por completo) o colocaron mal la identificación del receptor. ¿Se puede subsanar? No lo sabemos, pero si te pasa sugerimos que escales el caso al Ministerio de Hacienda y compartas la respuesta que te den.

¿Y qué hay del JSON que debemos enviar?

Bueno, el JSON que se envía es virtualmente el mismo que se usa para cualquier otro tipo de documento; con sólo un nuevo atributo: consecutivoReceptor. Es importante recalcar que el API REST que se emplea es el mismo de cualquier otro documento.

• clave: que corresponde a la clave de 50 posiciones del documento electrónico (Factura, Tiquete, Nota de Débito o Nota de Crédito). Debe ser la misma que pusimos en el XML en el atributo Clave
• fecha: fecha de emisión del documento, codificada en formato yyyy-MM-dd'T'HH:mm:ssZ como se define en http://tools.ietf.org/html/rfc3339#section-5.6.
• emisor: que sería el emisor del documento que enviamos. En este ejemplo se ilustra el caso de una persona jurídica. Aunque se soportan otros tipos de identificación.
• receptor: que sería el contribuyente que está respondiendo y que debe ser el mismo contribuyente que realiza el proceso de autenticación.
• callbackUrl: es un atributo opcional que corresponde a un URL para que el Ministerio de Hacienda envíe la respuesta de aceptación o rechazo, por medio de un mensaje JSON.
• consecutivoReceptor: este atributo corresponde al mismo valor del NumConsecutivoReceptor que colocamos en el XML. Es obligatorio para un mensaje de receptor.
• comprobanteXml : es un campo obligatorio y de acuerdo a la documentación consiste del Comprobante electrónico XML firmado por el obligado tributario (que en este caso es el receptor) utilizando XAdES-EPES según lo define el estándar ETSI TS 101 903 v1.3.2 o superior. El texto del XML. debe convertirse a un byte array y codificarse en Base64. El mapa de caracteres a utilizar en el XML y en la codificación Base64 es UTF8.

{% highlight json %}
{
“clave”: “50601011600310112345600100010100000000011999999999”,
“fecha”: “2016-01-01T00:00:00-0600”,
“emisor”: {
“tipoIdentificacion”: “02”,
“numeroIdentificacion”: “3101123456”
},
“receptor”: {
“tipoIdentificacion”: “02”,
“numeroIdentificacion”: “3101123456”
},
“consecutivoReceptor”: “00100001050000000001”
“comprobanteXml”: “PD94bWwgdmVyc2lvbj0iMS4wIiA/Pg0KDQo8ZG9tYWluIHhtbG5zPSJ1cm46amJvc3M6ZG9tYWluOjQuMCI+DQogICAgPGV4…”
}
{% endhighlight %}

¿Y cómo sé si se aceptó o rechazó el mensaje?

Cuando se hace el envio del JSON hacia la plataforma, el API retorna un código HTTP 202 y además un header Location. Es con ese header que obtienes la dirección para obtener la respuesta del Ministerio de Hacienda. Esa respuesta, al igual que cualquier otra que envia la plataforma, te dice si el documento se rechazó (y por que causa), si se acepta o si se acepta con algún mensaje de advertencia.

No puedes usar el API /recepcion/{clave}, pues este se dispuso únicamente para validar los documentos (factura, tiquete, nota de débito y nota de crédito). Si enviaras la clave, lo que te daría (suponiendo que fueras el emisor), sería el estado del documento original. No de tu mensaje de receptor.

Conclusión

Esperamos que con este artículo le resulte más claro a nuestra audiencia como hacer uso de los mensajes de receptor y aclarar las interrogantes más comunes de este tipo de documento.

Referencias

• Schema del Mensaje de Receptor v4.2
• Resolución de Comprobantes Electrónicos DGT-R-48-2016
• Anexos y Estructuras v 4.2
• Documentación del REST API