[Agregar] [Apartado Mecanismo de Seguridad]

[JeanCarlosChavarriaHughes]

Referencia:

146. Se ajusta la descripción del nodo de firma actual, ampliando el uso del estándar actual permitiendo la inclusión de la firma de receptor en comprobantes a crédito y las firmas para endoso:
     • Se incorporan ejemplos ampliando el uso del estándar actual donde se utilizan la contra firma del receptor en comprobantes de crédito y las contra firmas para endosante y endosatario en casos de endoso.
     • Se cambia el ejemplo de firma para que tenga la información del Policy en la versión v4.4
     • Asegurarse de incluir el atributo: <xades:ClaimedRole>

Descripción completa:
▪Firma XadES-EPES v.1.3.2. o superior. Este nodo, por medio del estándar de XadES permite
realizar varias firmas al documento XML, con el fin que el emisor pueda cumplir con lo estipulado
en la normativa vigente, con relación a que todo comprobante debe de ser firmado por el emisor
electrónico.
▪Todo archivo XML generado por un emisor-receptor electrónico, Emisor electrónico no
confirmante y receptor electrónico-no emisor, que se encuentre obligado hacer uso de
comprobantes electrónicos debe de ser enviado a la Dirección General de Tributacion para su
respectiva validación una vez generado y firmado por el emisor.
▪En caso de la Factura de Compra la misma debe de ser firmada por el Receptor que es quien la
emite y la envía al validador.
▪Adicionalmente en aquellos casos donde el “Emisor-receptor-electrónico” requiera que dicho
comprobante cuente con la firma del receptor con el objetivo de cumplir con lo establecido en la
Ley 8454 denominada “Ley de certificados, firmas digitales y documentos electrónicos”, para que
dicho comprobante se convierta en un título ejecutivo tal como lo establece los artículos 460 y
460 bis del código de comercio, debe utilizar el atributo xades:ClaimedRole indicando la
función que está ejerciendo, en este caso del “Receptor”
▪En caso de requerirse el endoso de los comprobantes Factura Electrónica o Factura Electrónica
de Exportación, tanto el endosante como el endosatario, posteriormente a la emisión del
comprobante electrónico, deberán incorporar la firma, la cual debe estar al amparo bajo la Ley
8454 denominada “Ley de certificados, firmas digitales y documentos electrónicos, emitidas por
las entidades bancarias. Para esto debe utilizar el atributo xades:ClaimedRole indicando la
función que está ejerciendo, en este caso, si es para el primer endoso, para el endosante el
nombre “Endosante1” y para el endosatario el nombre “Endosatario1” y así sucesivamente
▪El comprobante electrónico que posea las firmas del receptor o endosante y endosatario, no
debe de ser enviado a la Dirección General de Tributacion al ser este comprobante únicamente
para fines comerciales, ya que para fines tributarios será válido únicamente el primer archivo
enviado por el emisor y aceptado por el Ministerio de Hacienda en el proceso de validación. Los
emisores electrónicos que no requieran estas firmas adicionales, no tendrán obligación de utilizar
el atributo xades:ClaimedRole
▪Ver Anexo 2 para visualizar el ejemplo de este mecanismo.

Anexos y Estructuras:
https://atv.hacienda.go.cr/ATV/ComprobanteElectronico/docs/esquemas/2024/v4.4/ANEXOS%20Y%20ESTRUCTURAS_V4.4.pdf

Link de Anexos y Estructuras:
https://atv.hacienda.go.cr/ATV/ComprobanteElectronico/docs/esquemas/2024/v4.4/ANEXOS%20Y%20ESTRUCTURAS_V4.4.pdf

Branch para subir el Pull Request:
https://github.com/CRLibre/API_Hacienda/tree/v4.4

Documentacion de Hacienda:
https://atv.hacienda.go.cr/ATV/ComprobanteElectronico/frmAnexosyEstructuras.aspx#

[fdelapena]

Es muy importante tener en cuenta que este tipo de firma se indica explícitamente que debe ser de la jerarquía de Firma Digital Certificada del BCCR (Firma Digital y Sello Electrónico), ya que no sería ya para fines tributarios, es esencial para factoreo y para ventas a crédito y tener un título ejecutivo con firmas reconocidas es fundamental. En resumen, los certificados de la jerarquía de hacienda no se podrán utilizar para endosantes, endosatarios y receptor. Sería conveniente que la API validara esto, si llegara a implementarlo. Sin embargo, la Firma Digital de Persona Física requiere una interfaz PKCS#11 y probablemente está fuera del alcance de esta herramienta.

[fdelapena]

A nivel código, con agregar el claimedRole sería suficiente para resolver este ticket. El código de la policy ya existía en versiones anteriores, aunque se actualizó en un PR anterior.

Las firmas de receptor/endoso están fuera del ámbito de emisión de comprobantes para fines tributarios y como se indica, las contra-firmas no se envían a hacienda, solo el XML de emisor.