Recepción de Documentos (Integradores Externos)

La API de Alanube cuenta con el servicio de recepción de documentos que son enviados hacia los usuarios de la misma. Para ello, se encuentran implementados un conjunto de endpoints específicos para tal fin. Los mismos, acordes a los estándares que la entidad fiscal establece y que todo integrador debe seguir.

Dicho conjunto de endpoints los encontrarás en este enlace: Buzón de documentos electrónicos

Cabe aclarar, que el conocer en detalle sobre el proceso de envío de documentos electrónicos hacia un receptor queda como responsabilidad del integrador externo, y no del usuario de la API. La presente guía describe el proceso en líneas generales con fines informativos hacia los usuarios.

A continuación, se describe de manera general el proceso de envío de documentos hacia un usuario receptor.

1. Solicitud de token para envío de documentos electrónicos

A fin de obtener un token que le permita a un emisor electrónico enviar un documento, este deberá completar un desafío para corroborar la autenticidad del mismo (del mismo modo que cuando se envía un documento hacia la entidad fiscal).

Como primer paso, se debe solicitar una "semilla" la cual no es más que un XML con cierto valor aleatorio, el cual deberá ser firmado por el emisor electrónico. La semilla puede ser obtenida a través de este endpoint.

A continuación, se ve un ejemplo de dicha semilla.

<?xml version="1.0" encoding="UTF-8"?>
<SemillaModel>
    <valor>$6a$20$L3lTo8z4xoN1gpoDGbZtQerJI/QnQuTmm2JPsYsMdw60h65bxFJiJ</valor>
    <fecha>2022-03-29T10:31:32-04:00</fecha>
</SemillaModel>

Una vez obtenida la semilla, la misma deberá ser firmada con el certificado digital de la compañía emisora (el mismo certificado que es usado para la firma de documentos electrónicos).

Una vez firmada la semilla, la misma deberá ser enviada al siguiente endpoint.

Dicho endpoint validará la firma de la semilla enviada, y si es correcta, otorgará un token como respuesta. Dicho token es el que deberá ser usado al momento de enviar los documentos electrónicos, siguiento el esquema Bearer Authentication.

A continuación, un ejemplo de respuesta:

{
    "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE2NDg2NDcxMjYsIm5iZiI6MTY0ODY0NzEyNiwiZXhwIjoxNjQ4NjUwNzI2LCJpc3MiOiJhbGFudWJlLmNvbSIsImp0aSI6IjcyMmMzODFiLTE4ZjItNGZhNy1iNzRmLTYxN2JmOWMzZTM3ZSJ9.ZkfNXwnnCuLV0bPW5BTKo9Dhx1A6RpE1FbsookaK5LY",
    "expedido": "2022-03-30 09:32:06",
    "expira": "2022-03-30 10:32:06"
}

2. Envío de un documento electrónico

Para el envío de documentos electrónicos se cuenta con dos enpoints:

Ambos endpoints reciben como parámetro de path el Id de la compañía a la cual se desea enviar el documento electrónico o aprobación comercial.

Es importante aclarar que la URL completa a la cual se debe enviar los documentos debe ser consultada al directorio de emisores-receptores de la entidad fiscal, mediante el endpoint que la misma dispone para tal fin.

A su vez, deberá ir adjunto el archivo XML firmado y aprobado por la entidad fiscal que contiene la información del documento electrónico o aprobación comercial.

3.1. Respuesta al recibir un documento electrónico

Como parte del proceso estándar, al recibir un documento electrónico, se debe emitir al emisor del documento un Acuse de Recibo como respuesta a su recepción. Dicho acuse de recibo, no implica la aprobación comercial del mismo, simplemente indica si dicho documento es recibido, o no.

Aclarando lo último dicho, un acuse de recibo tampoco implica que dicho documento es recibido, ya que hay casos en los que se puede expresar el no recibir un documento por diversas razones, por ejemplo, la firma electrónica del documento es incorrecta.

Se podría pensar como que existen dos posibilidades:

Respuesta con un Acuse de Recibo (se expresa que se recibe el documento)
Respuesta con un Acuse de No Recibo (se expresa que no se recibe el documento)

A continuación, se muestra un ejemplo de un Acuse de Recibo (correspondiente a un acuse afirmativo):

<?xml version="1.0" encoding="UTF-8"?>
<ARECF>
  <DetalleAcusedeRecibo>
    <Version>1.0</Version>
    <RNCEmisor>132109122</RNCEmisor>
    <RNCComprador>123456789</RNCComprador>
    <eNCF>E330110000003</eNCF>
    <Estado>0</Estado>
    <FechaHoraAcuseRecibo>03-03-2022 09:19:53</FechaHoraAcuseRecibo>
  </DetalleAcusedeRecibo>
  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
    <!-- ...información propia de la firma... -->
  </Signature>
</ARECF>

3.2. Respuesta al recibir una aprobación comercial

Como parte del proceso estándar, al recibir una aprobación comercial, se responderá con un objeto JSON y un código HTTP 200 para el caso de que la aprobación comercial es recibida, y un código HTTP 400 en los casos en que la aprobación comercial no es recibida. A su vez, en el objeto JSON devuelto se encontrará la razón de la no aceptación de la aprobación comercial.

A continuación un ejemplo de objeto JSON (para el caso que la aprobación comercial es recibida):

{
    "estado": "OK",
    "codigo": "200",
    "mensajes": [
        "Commercial approval received"
    ]
}

A continuación un ejemplo de objeto JSON (para el caso que la aprobación comercial no es recibida):

{
    "estado": "Bad Request",
    "codigo": "400",
    "mensajes": [
        "Signature verification did not pass."
    ]
}