Flujo y Codigos Comprobantes Electronicos - Hacienda
Flujo y Codigos Comprobantes Electronicos - Hacienda
Flujo y Codigos Comprobantes Electronicos - Hacienda
Nº 2016CD-000019-0009100001
Diciembre 2018
Página 1 de 13
Detalle del Flujo de Integración de Comprobantes
Electrónicos y Códigos de Validación
Tabla de Contenido:
Página 2 de 13
Detalle del Flujo de Integración de Comprobantes
Electrónicos y Códigos de Validación
1 Flujo de Integración
La integración con la plataforma del Ministerio de Hacienda para Comprobantes
Electrónicos se puede dividir en dos pasos principales:
Acceder el IDP y obtener un token
Enviar o consultar un documento electrónico
1.1 IDP
En el caso del IDP (Identity Provider) se debe tener claro que se encuentra basado en el
estándar OpenID Connect (OIDC); es decir, constituye una extensión de OAuth 2.0
El URL para obtener un token productivo es
https://idp.comprobanteselectronicos.go.cr/auth/realms/rut/protocol/openid-connect/token
Y debe enviarse los parámetros de grant_type, client_id, username y password que están
documentados.
Las respuestas que se pueden brindar son:
Código de HTTP Mensaje de Estado Descripción
200 OK Quiere decir que la petición fue recibida
correctamente y se retorna un JSON con la
información del access_token y refresh_token,
entre otros.
400 Bad Request La petición es inválida o mal formada
401 Unauthorized El client_id o token es inválido
403 Forbidden Acceso no permitido
50X Error Un error sobre el IDP; en este caso la petición
no pudo ser atendida.
Gráficamente, el único código HTTP que permite continuar con el siguiente paso es el
HTTP 200.
Página 3 de 13
Detalle del Flujo de Integración de Comprobantes
Electrónicos y Códigos de Validación
1 https://www.hacienda.go.cr/ATV/ComprobanteElectronico/docs/esquemas/2016/v4.2/comprobantes-
electronicos-api.html#recepcion_post
2 En el JSON del API hay un atributo que define el URL utilizado para que Hacienda envíe la respuesta de
aceptación o rechazo, se va a enviar un mensaje JSON, por medio de un canal HTTP/HTTPS utilizando POST.
3 En el ambiente de STAGING; pero se debe considerar la posibilidad de establecer ese control en PRODUCCION.
4 De 15 a 20 minutos
Página 4 de 13
Detalle del Flujo de Integración de Comprobantes
Electrónicos y Códigos de Validación
Página 5 de 13
Detalle del Flujo de Integración de Comprobantes
Electrónicos y Códigos de Validación
6 En el ambiente de STAGING; pero se debe considerar la posibilidad de establecer ese control en PRODUCCION.
Página 6 de 13
Detalle del Flujo de Integración de Comprobantes
Electrónicos y Códigos de Validación
El código esperado es un 200; pero se debe prestar atención a un HTTP 404; pues este
quiere decir que la clave consultada NO existe en la plataforma de Comprobantes. Tal
situación se da si el hacer el POST no se recibió un 202; por lo cual carece de sentido
hacer invocaciones posteriores al método GET; ya que siempre retornaría un 404.
Los sistemas informáticos de los contribuyentes deben tomar en cuenta que no deben
hacer consultas a claves que no han enviado.
Por último, en el caso del estado de RECHAZADO; si este error se detecta que es por la
firma, la plataforma de Hacienda hace un segundo intento de validación 7 en un plazo de
10 minutos; por lo cual el contribuyente debe validar una segunda ocasión este
documento. Lo anterior, dado que es posible que ya este aceptado. De igual manera,
podría recibir un segundo callback con estado de ACEPTADO.
Página 7 de 13
Detalle del Flujo de Integración de Comprobantes
Electrónicos y Códigos de Validación
Página 8 de 13
Detalle del Flujo de Integración de Comprobantes
Electrónicos y Códigos de Validación
3 Proceso de Validación
En lo que compete al proceso de validación de un documento, la plataforma siempre
realiza estos pasos:
Página 9 de 13
Detalle del Flujo de Integración de Comprobantes
Electrónicos y Códigos de Validación
Página 10 de 13
Detalle del Flujo de Integración de Comprobantes
Electrónicos y Códigos de Validación
-29 La clave numérica utilizada para este archivo XML ya existe en nuestras bases Rechazo
de datos.
Y en el caso del Mensaje de Receptor, corresponde a:
El comprobante al cual se está haciendo referencia en el espacio denominado
'clave del comprobante', no se encuentra registrado en las bases de datos de
la Administración Tributaria, favor revisar dicha clave. o
El campo denominado 'Monto total de impuesto' es un campo obligatorio por
lo cual debe de ingresar la información solicitada con el formato establecido
o
El campo denominado 'Monto total de impuesto' no coincide con el
documento al cual se referencia. o
El campo denominado 'Monto total de impuesto' no coincide con el
documento al cual se referencia. o
El campo denominado 'Total de la Factura' es un campo obligatorio por lo
cual debe de ingresar la información solicitada con el formato establecido" o
El campo denominado 'Total de la Factura' no coincide con el monto del
documento electrónico que se referencia. o
El campo denominado 'Total de la Factura' no coincide con el monto del
documento electrónico que se referencia.
-99 La numeración consecutiva del comprobante que se está utilizando para este Rechazo
archivo XML ya existe en nuestras bases de datos.
-25 El nodo denominado 'Nombre o razón social del emisor' es un campo Rechazo
obligatorio por lo cual debe de ingresar la información solicitada con el
formato establecido
-17 Número de cédula física/ jurídica/NITE/DIMEX emisor no posee la estructura Rechazo
establecida para el mismo
-77 El correo electrónico del emisor no posee la estructura establecida para el Rechazo
mismo
-37 No se encuentra inscrito ante la Dirección General de Tributación, favor Rechazo16
proceder a cumplir con este requisito formal antes de volver a enviar el
archivo XML para su validación.
-37 El 'Emisor o Receptor' del comprobante se encuentra en las bases de la Advertencia17
Dirección General de Tributación con el estado de 'Estado en ATV', favor
proceder a revisar dicho estado antes de remitir nuevamente el archivo XML
a la Dirección General de Tributación
-30 El campo denominado 'Provincia Emisor o Receptor' no posee la estructura Rechazo
establecida para el mismo.
-30 El campo denominado 'Cantón Emisor o Receptor ' no posee la estructura Rechazo
establecida para el mismo.
-30 El campo denominado 'Distrito Emisor o Receptor ' no posee la estructura Rechazo
establecida para el mismo.
-30 El campo denominado 'Barrio Emisor o Receptor ' no posee la estructura Rechazo
Página 11 de 13
Detalle del Flujo de Integración de Comprobantes
Electrónicos y Códigos de Validación
Página 12 de 13
Detalle del Flujo de Integración de Comprobantes
Electrónicos y Códigos de Validación
Página 13 de 13