Costa Rica: Recepción de documentos (MS)

1. PROCESO DE RECEPCIÓN DE UN XML

Este proceso permite recibir diferentes tipos de comprobantes de clientes y proveedores a través de los canales que ofrece Gosocket. Una vez recibidos, tanto el emisor como el receptor podrán consultar los documentos en la bandeja de Recibidos de Inbox, junto con su respectiva representación gráfica y archivos adjuntos.

Asi mismo, nuestro sistema realiza una serie de validaciones automáticas para garantizar que la estructura e integridad de la información cumplan estrictamente con las exigencias de las entidades tributarias.

En la siguiente imagen se describe, paso a paso, el flujo de recepción de documentos dentro de la plataforma Inbox:

Proceso de recepción Costa Rica

1. Métodos de envío del documento XML en Gosocket

El proveedor tiene la posibilidad de enviar el documento XML de tres maneras a la plataforma de Gosocket:

a. El proveedor realiza la carga manual del archivo XML mediante la opción Upload de Gosocket. Los requisitos y condiciones para este proceso se detallan en la sección Carga manual.

b. El proveedor envía el documento XML por la casilla de intercambio de Gosocket. Los requisitos y condiciones para este proceso se detallan en la sección Casilla de intercambio.

c. El proveedor carga el documento XML a través del API Recepción de Gosocket. Los requisitos y condiciones para este proceso se detallan en la sección API´s Recepción.

información

Nota: Al utilizar cualquiera de los siguientes canales de recepción de documentos:

• Casilla de intercambio
• Carga manual de XML (opción Upload)
• API de Recepción

El sistema ejecutará automáticamente las validaciones de esquema, firma y la correspondiente validación ante la Entidad Tributaria (ET).

2. Recepción y validación de documentos en Gosocket

El portal de Gosocket descarga y procesa el XML. Cuando se trata de un documento tributario, entra a un proceso de validación de recepción.

3. Validación de esquema del documento

En primer lugar, se realiza una validación de esquema al documento XML para garantizar que cumpla con el formato establecido por la entidad tributaria. Dependiendo del resultado de esta validación, el proceso puede derivar en uno de los siguientes escenarios:

d. Fallido: El documento no cumple con el formato fiscal, el flujo de recepción del documento quedará detenido por el error de esquema, se registrará en Gosocket con estado Error de esquema y en la interfaz se mostrará el ícono y en las notas del documento se detallará el motivo del rechazo, asi:

Icono error de esquema en inbox

Detalle del documento sección Notas - Error de Esquema

Detalle del procesamiento del XML del error de esquema

e. Exitoso: Si la validación del esquema del XML es correcta, el documento continuará con el flujo de recepción.

Detalle del documento sección Notas - Validación de esquema exitosa

información

Configuración especial: El XML presenta error de esquema, pero si se activa la configuración, esta opción permite continuar el flujo de recepción:

Esta característica se puede activar de forma independiente por cada empresa. Su objetivo es que, si se detecta un error de esquema en el XML al recibir el documento en Gosocket, el detalle del error puntual se registrará automáticamente en la sección de "Notas" del documento.

A pesar de este hallazgo, el documento continuará con su flujo normal hacia las siguientes validaciones de recepción, tales como la verificación de la firma y de la entidad tributaria.

El documento quedará en Inbox de la siguiente manera:

• En Gosocket el documento quedará en estado Validado ET con error esquema y se mostrará el icono naranja, así:

Para obtener más detalles sobre cómo configurar esta funcionalidad, consulte el siguiente apartado: Configuración XML presentan errores de esquema y continua el flujo de recepción. / XML Configuration Presents Schema Errors and Reception Flow Continues

4. Validación de firma electrónica del documento

En segundo lugar, se realiza una validación de firma electrónica del documento para garantizar que la información no haya sido alterada. De esta validación se puede obtener uno de los siguientes resultados:

f. Fallido: Significa que el documento ha sido alterado, el flujo de recepción del documento quedará detenido por el error de firma por lo que se registrará en Gosocket con estado Error de Firma, en la interfaz se mostrará un ícono y en las notas de la vista previa se indicará el motivo del rechazo, así:

Icono errror de firma en Inbox

Detalle del documento sección Notas - Error de Firma

Detalle del procesamiento del XML del error de esquema

g. Exitoso: Si la validación de la firma electrónica del XML es correcta, el documento continuará con el flujo de recepción.

Detalle del documento sección Notas - Validación de firma exitosa

5.Validación del documento ante la Entidad Tributaría

En tercer lugar, se realiza la validación de consulta ante la Entidad Tributaria. De esta validación, se puede obtener varios resultados:

h. Documento tiene una excepción interna por Gosocket ❗

Al realizar la consulta de validación ante la Entidad Tributaria del documento y Gosocket no logra conectarse con el servicio de la ET o hay errores de comunicación con el servicio, el documento cambia su estado a ERROR y se le asignara el icono ❗.

Icono Error en inbox: No hubo comunicación con la ET.

Detalle del documento sección Notas - Validación del documento ante la ET con error en la comunicación.

i. En este punto del proceso cuando el documento si existe en la entidad tributaria , se derivan dos respuestas:

• Si existe el documento, pero este tiene un estado Rechazado (Para más detalle en el literal j)
• Si existe el documento, pero este tiene un estado Aceptado (Para más detalle en el literal k)

j. Documento Rechazado por la Entidad Tributaria

Si el documento existe en la ET, pero hay algún motivo de rechazo en la Entidad Tributaria, su estado será Rechazado y se le asignara el icono .

Icono Rechazada en inbox: Validación del documento ante la ET rechazada

Detalle del documento sección Notas - Validación del documento ante la ET rechazado

k. Documento Aceptado por la Entidad Tributaria

Si el resultado de las validaciones anteriores (Esquema y Firma) es satisfactorio y la consulta ante la entidad tributaria es exitosa, el documento se registrará en Gosocket con el estado Aceptado. En la interfaz, este estado se identificará con un ícono de verificación (check) verde.

Icono Aceptado en inbox: Validación del documento ante la ET exitosa

Detalle del documento sección Notas - Validación del documento ante la ET exitosa

l. Reintetos automáticos cuando el documento tiene estado no disponible en la ET .

En esta etapa del proceso, cuando el documento no existe en la Entidad Tributaria, se indica que el documento recibido no se encuentra registrado en la ET. Para este escenario, se ejecutan las siguientes acciones sobre el documento:

• En Gosocket, el documento quedará con el estado No Disponible en ET y se le asignará el ícono correspondiente .

• Se activará un proceso de reintentos automáticos, que consiste en realizar múltiples consultas a la Entidad Tributaria para verificar si el documento cambia a un estado diferente de No Disponible en ET. Si durante alguno de estos reintentos se obtiene un estado distinto, el documento actualizará automáticamente tanto su estado como su ícono correspondiente.

• Si, después de completar todos los reintentos, el documento continúa sin estar disponible en la Entidad Tributaria, conservará el estado No Disponible en ET y mantendrá el ícono correspondiente .

• El parametro actual de reintentos es 30 intentos en 1 hora (cada 2 minutos realiza el reintento de consulta).

Cuando se recibe el documento y se realizan los reintentos de consulta ante la ET, en la sección notas se identifica el siguiente mensaje:

y dentro del detalle del documento en el código “TAX-CHECK” indicará que inició la validación ante la ET:

Una vez se superen los reintentos automaticos (aproximadamente una hora después) , se visualizará el estatus definito del documento ante la ET, así:

y en el detalle del documento se mostrará el mensaje:

“Consulta Integrada en la ET: No existe. Se realizaron 30 intentos. Se realizó reproceso manual.”

y en la otra línea se mostrará otro mensaje: “Se realizó la cantidad máxima de reintentos para consulta de estado ante la ET”, así:

y posterior a estos reintentos se derivan dos respuestas:

m. Si después de los 30 intentos el documento sigue sin encontrarse, quedará definitivamente en estado No Disponible en ET, mostrando el siguiente icono en el Inbox.

Icono Rechazada en inbox: Validación del documento ante la ET r

n. Si durante estos reintentos el documento es encontrado en la ET, se actualiza su estado donde el proceso continúa y se derivan dos respuestas:

• Si existe el documento, pero este tiene un estado Rechazado (Para más detalle en el literal j)
• Si existe el documento, pero este tiene un estado Aceptado (Para más detalle en el literal k)

6. Iconografía en inbox del resultado de las validaciones de recepción

Por último, tanto el emisor como el receptor podrán consultar los resultados de las validaciones del documento XML en Inbox, así:

No.	Estado	Icono en la interfaz de inbox
o	Documento tiene error de esquema
p	Documento tiene error de firma
q	Error de comunicación con la Entidad Tributaría
r	Documento quedó Aceptado por la Entidad Tributaría
s	Documento quedó Rechazado por la Entidad Tributaría
t	Documento no disponible o no existe en la Entidad Tributaría

7. Emisión de los acuses comerciales

Una vez que el documento fue recibido y validado, pueden emitirse los acuses mercantiles o comerciales que sean necesarios según su criterio desde la plataforma de inbox o en su defecto pueden ser enviados por la casilla de intercambio. Esto se explica con mayor detalle en el apartado Acuses comerciales.

---

2. REPROCESAMIENTO DE DOCUMENTOS MANUALMENTE

Adicional, en Inbox se implementó un botón que permite reprocesar manualmente los documentos tributarios, que tengan estado “ERROR” ❗, “No Disponible en ET” , “Error de firma” y “Error de esquema” .

información

Nota: Esta opción solo permite reprocesar documentos que hayan sido enviados por la casilla de intercambio, la API de recepción o la carga manual (upload).

Esta opción de reprocesamiento la encontraremos en la siguiente ruta según corresponda:

• Inbox/Recibido/Opciones/Acciones/Reprocesar documento sin validar esquema.
• Inbox/Recibido/Opciones/Acciones/Reprocesar documento sin validar firma.
• Inbox/Recibido/Opciones/Acciones/Reprocesar documento.

Acompañado de un selector que, como su nombre lo indica, permitirá seleccionar de manera independiente un Comprobante Electrónico o un conjunto de ellos.

Seguido, se mostrará una ventana emergente en la cual, el usuario debe confirmar que desea revalidar los documentos previamente seleccionados.

Una vez que se generó el reprocesamiento, se mostrará baner en la parte superiro de la pagina que indicará que el o los documento se enviaron a reprocesar:

y finalmente, para cualquiera de los tres reprocesamientos que se genere por medio de esta opción en la sección notas se indicará:

• Registra el correo del usuario que realizo el reprocesamiento del documento.
• Genera una nota “Documento procesado sin validación de esquema” o “Documento procesado sin validación de firma”
• El documento continua el flujo de validación de recepción.

Este botón permite realizar un reprocesamiento de las diferentes validaciones del proceso de recepción:

2.1. Reprocesar documento sin validar esquema:

Permite que el documento pase por las validaciones de recepción sin tener en cuenta la validación de esquema, sin embargo, al seleccionar el documento y aplicarle este reporcesamiento sin validar esquema, el sistema:

• Registra el correo del usuario que realizo el reprocesamiento del documento.
• Genera una nota “Documento procesado sin validación de esquema”.
• El documento continua el flujo de validación de recepción.

2.2. Reprocesar documento sin validar firma:

Permite que el documento pase por las validaciones de recepción sin tener en cuenta la validación de firma, sin embargo, al seleccionar el documento y aplicarle este reporcesamiento sin validar firma, el sistema:

• Registra el correo del usuario que realizo el reprocesamiento del documento.
• Genera una nota “Documento procesado sin validación de firma”.
• El documento continua el flujo de validación de recepción.

2.3. Reprocesar documento:

Permite reprocesar el documento desde cero y realiza nuevamente las validaciones de recepción sin omitir ninunga validación, sin embargo, al seleccionar el documento y aplicarle este reporcesamiento, el sistema:

• Registra el correo del usuario que realizo el reprocesamiento del documento.
• Realiza las validaciones de recepción sin omitir ninguna de ellas.

---

3. MÉTODOS DE ENVÍO DE UN XML

Actualmente, existen tres métodos para la recepción de documentos al sistema:

• Carga manual: Importación del archivo XML mediante la opción Upload en Gosocket.
• Casilla de intercambio: Flujo de entrada automatizado por buzón de intercambio.
• API de recepción: Conexión vía API para procesamiento integrado.

3.1. Carga manual del XML a través del Upload en Gosocket

Gosocket dispone de una herramienta dentro de la plataforma Inbox que permite al proveedor cargar directamente el archivo XML de sus documentos.

• Ruta de acceso: Menú principal > Upload > Carga Manual.

Desde esta sección, el usuario puede seleccionar el archivo XML desde el explorador de su dispositivo o, si lo prefiere, arrastrarlo y soltarlo directamente en la interfaz.

Una vez recibido el documento, la solución inicia automáticamente el flujo de procesamiento y validación.

Una vez se reciba el archivo XML por la opción carga manual, se identificará:

a. Cuantos archivos en total XML se recibieron, cuantos procesados con éxito y cuantos tienen error.

b. Al dar clic en el botón “Detalles” se mostrará un popup con el “Detalle de Errores” identificando los posibles errores que puede contener el archivo XML cargado manualmente por esta opción y en caso contrario que el documento no tenga errores, se mostrará un detalle que se cargó en la plataforma de Gosocket con éxito:

c. Finalmente, el documento se visualizará en la bandeja de recibidos de inbox, con todas las validaciones realizadas.

3.1.1. Consideraciones para la carga manual del XML

• En una sola carga se podrá cargar hasta 100 archivos XML.
• Se realizarán las validaciones de esquema, firma y Entidad Tributaria.
• Deberán enviarse los documentos tributarios estipulados por la Entidad Tributaria en un formato XML.

Los documentos tributarios que se pueden recibir son:

• Factura electrónica.
• Nota Crédito.
• Nota Débito.
• Tiquete electrónico.
• Factura de Exportación.

3.2. Casilla de intercambio

Es el proceso mediante el cual el proveedor envía sus archivos XML a través de un buzón de correo electrónico. Cada país tiene asignadas direcciones específicas según el entorno de trabajo.

Las casillas que deben utilizarse, de acuerdo con el ambiente, son:

• Sandbox (Pruebas): cr_ms_sbx@inbound.gosocket.com
• Productivo: cr@recepcionprd.gosocket.net

información

Nota: En caso de necesitar una casilla de intercambio personalizada para un cliente, se debe escalar al equipo comercial dado que esta solicitud genera un costo adicional.

3.2.1. Consideraciones para la casilla de intercambio

Es importante tener en cuenta los siguientes puntos para el envío de los documentos ya que esto evitará que sean rechazados por la aplicación.

a. Los documentos tributarios que se pueden enviar por la casilla de intercambio son:

• Factura electrónica.
• Nota Crédito.
• Nota Débito.
• Tiquete electrónico.
• Factura de Exportación.

b. Deberán enviarse los documentos tributarios estipulados por la Entidad Tributaria en un formato XML.

c. Pueden enviarse de forma individual o varios XML en un mismo correo.

d. Pueden enviarse varios XML comprimidos en el archivo y solo permitira extención .zip.

e. Los archivos XML o comprimidos (.zip) debe estar adjuntos al correo de la casilla fascilitada por Gosocket.

f. Pueden enviarse documentos adjuntos, como el PDF de la factura u otros que se requieran.

g. El peso máximo permitido en un correo electrónico, donde, se relacionen archivos XML y PDF es de 20MB.

h. La solución tiene la posibilidad de realizar el procesamiento de los PDF de representación gráfica en caso tal de que esta venga y documentos adjuntos que lleguen a la casilla de correo donde una vez recibido se almacenan asociándolos a su respectivo documento permitiendo la descarga dentro de Inbox.

El proceso funciona de la siguiente manera:

• Si a la casilla de intercambio llega un documento XML y adicional un archivo PDF con el mismo nombre, por ejemplo: Factura12345.xml y Factura12345.pdf, se entiende que el archivo .pdf es la representación gráfica del DTE por lo que se sincroniza de esa forma en Gosocket y estará disponible para su consulta.
• Si a la casilla llega un documento XML con más de un archivo adjunto de cualquier extensión se asocian como documentos adjuntos.

aviso

Nota: Si hay archivos PDFs con un nombre diferente al del XML se considerarán como documentos adjuntos.

• Para el envío de adjuntos se recomienda enviar cada DTE con sus adjuntos de forma separada ya que en el caso de que llegue más de un documento XML solo se realizará el almacenamiento de la representación gráfica siempre y cuando el archivo PDF contenga el mismo nombre de cada XML correspondiente, el resto de los archivos adjuntos no se procesarán puesto que no hay forma de saber a qué documento asociarlos.
• También se pueden asociar adjuntos después del envío del XML, por ejemplo, si se realiza el envío del XML sin adjuntos, se puede enviar posteriormente otro mail con documentos adjuntos (PDF, Excel, Word, etc) y estos serán asociados el documento previamente enviado, siempre y cuando en el segundo mail se incluya también el XML.

3.3. API´s Recepción

Para el proceso de recepción de documento, Gosocket ofrece dos API´s que permiten realizar el envio de XML a la plataforma de Gosocket:

3.3.1. UploadZipDocument:

Esta API permite enviar una petición que incluye uno o varios archivos XML y PDF hacia Gosocket, empaquetados conjuntamente en un archivo comprimido (.zip). Una vez recibido, el sistema procesa el documento, genera el registro correspondiente y lo almacena de forma segura en la plataforma.

a. Gestión de seguimiento (Tracking)

Para realizar el seguimiento detallado del procesamiento del PDF end to end, desde que el PDF ingresa a la plataforma por la casilla de intercambio, hasta que el proveedor envía a Gosocket el XML y el PDF a Gosocket, a todo este proceso se le asigna dos identificadores únicos denominados "externalId" y "batchId".

b. Carga y almacenamiento

La API gestiona la recepción del archivo .zip, donde, el cual debe contener el PDF y su respectivo XML en el formato nativo de Gosocket para su correcta integración en el ecosistema.

Esta API permite la recepción, procesamiento y almacenamiento de comprobantes electrónicos en la plataforma de Gosocket.

c. Acciones de procesamiento post-almacenamiento

Una vez que el documento ha sido almacenado correctamente en Inbox, permitirá realizar las siguientes acciones:

• Validaciones de recepción (Automática): Verificación técnica del cumplimiento de estándares, incluyendo:

o   Validación de Esquema.

o   Integridad de la Firma Electrónica del comprobante.

o   Validaciones ante la Entidad Tributaria correspondiente: Indica si el documento fue aceptado, rechazado o si presenta errores de validación por el ente regulador tras la validación fiscal.

• Mensaje receptor (Automática): Aplicación de eventos de mensaje receptor según la normativa vigente de la entidad tributaria.
• Validaciones Smart Supply (Configuración a demanda): Aplicación de reglas lógicas y flujos de aprobación configurados en el módulo Smart Supply.
• Distribución de archivos (Configuración bajo demanda): Una vez que el documento ha sido procesado en la plataforma Gosocket, y basándose en la parametrización previa de las reglas de distribución, el sistema ejecuta la transferencia automatizada de los archivos hacia los destinos técnicos configurados. Esta funcionalidad permite la integración con diversos entornos, tales como:

o   Servidores Windows.

o   Protocolos de transferencia de archivos (SFTP / FTP).

o   Envío automatizado por correo electrónico.

aviso

Puede consultar los detalles de configuración de la API de Recepción en el siguiente enlace: API Recepción.zip - Genérica / API Reception.zip - Generic

3.3.2. SendDocumentToUpload:

Esta API permite enviar una petición que incluye un único XML hacia Gosocket. Una vez recibido, el sistema procesa el documento, genera el registro correspondiente y lo almacena de forma segura en la plataforma.

a. Carga y almacenamiento

La API gestiona la recepción del archivo en formato XML para su integración en el ecosistema de Gosocket:

• Ingesta: Carga el documento directamente en el módulo Inbox de Gosocket por medio del  enpoint: POST - SendDocumentToUpload
• Persistencia: Asegura el almacenamiento del archivo XML en los servidores de la plataforma para su posterior gestión.

b. Gestión de seguimiento (Tracking)

La ejecución exitosa de la API genera un identificador único denominado trackId. Este valor es devuelto en la respuesta y es indispensable para:

• Realizar el seguimiento detallado del estado del procesamiento.
• Consultar el resultado de la carga mediante el endpoint: GET- GetDocumentUploadStatus

c. Acciones de procesamiento post-almacenamiento

Una vez que el documento ha sido almacenado correctamente en Inbox, permitirá realizar las siguientes acciones:

• Validaciones de recepción (Automática): Verificación técnica del cumplimiento de estándares, incluyendo:

o   Validación de Esquema.

o   Integridad de la Firma Electrónica del comprobante.

o   Validaciones ante la Entidad Tributaria correspondiente: Indica si el documento fue aceptado, rechazado o si presenta errores de validación por el ente regulador tras la validación fiscal.

• Mensaje receptor (Automática): Aplicación de eventos de mensaje receptor según la normativa vigente de la entidad tributaria.
• Validaciones Smart Supply (Configuración a demanda): Aplicación de reglas lógicas y flujos de aprobación configurados en el módulo Smart Supply.
• Distribución de archivos (Configuración bajo demanda): Una vez que el documento ha sido procesado en la plataforma Gosocket, y basándose en la parametrización previa de las reglas de distribución, el sistema ejecuta la transferencia automatizada de los archivos hacia los destinos técnicos configurados. Esta funcionalidad permite la integración con diversos entornos, tales como:

o   Servidores Windows.

o   Protocolos de transferencia de archivos (SFTP / FTP).

o   Envío automatizado por correo electrónico.

aviso

Puede consultar los detalles de configuración de la API de Recepción en el siguiente enlace: API Recepción XML Base64 / Reception API

---

4. MENSAJE RECEPTOR

El acuse comercial tiene la finalidad de validar los documentos tributarios ante la Entidad Tributaria y como resultado, tendremos un cambio de estado dentro de nuestra bandeja de documentos recibidos en el Inbox de Gosocket.

Mediante el uso de estos eventos el receptor informa la recepción, aceptación o rechazo de cada documento.

Estos eventos se pueden generar desde dos puntos diferentes de Inbox que exploraremos a continuación.

Actualmente existe el envío del acuse comercial a los documentos recibidos de la siguiente manera:

**1.**Mensaje receptor:

a. Aprobado

b. Aprobado parcialmente

c. Rechazado

Una vez recibidos los documentos en inbox y superado las validaciones de recepción, Gosocket permite aplicar los acuses comerciales de la siguiente manera:

3.1. Recibir los acuses comerciales por la casilla de intercambio

3.2. Emitir manualmente el acuse comercial para estos documentos.

4.1. Recepción de acuses comerciales por la casilla de intercambio

Para recibir los acuses comerciales a través de la casilla de intercambio, el archivo debe cumplir estrictamente con la estructura específica exigida por la ET y contar con formato XML.

<ApplicationResponse
xmlns="urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2"
xmlns:sts="dian:gov:co:facturaelectronica:Structures-2-1"
xmlns:xades="http://uri.etsi.org/01903/v1.3.2#"
xmlns:xades141="http://uri.etsi.org/01903/v1.4.1#"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<ext:UBLExtensions>
...
</ext:UBLExtensions>
<cbc:UBLVersionID>UBL 2.1</cbc:UBLVersionID>
<cbc:CustomizationID>1</cbc:CustomizationID>
<cbc:ProfileID>DIAN 2.1: ApplicationResponse de la Factura Electrónica de Venta</cbc:ProfileID>
<cbc:ProfileExecutionID>1</cbc:ProfileExecutionID>
<cbc:ID>0000000000000000000</cbc:ID>
<cbc:UUID schemeID="1" schemeName="CUDE-SHA384">000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000</cbc:UUID>
<cbc:IssueDate>2026-06-30</cbc:IssueDate>
<cbc:IssueTime>15:14:00-05:00</cbc:IssueTime>
<cbc:Note>OK</cbc:Note>
<cac:SenderParty>
...
</cac:SenderParty>
<cac:ReceiverParty>
...
</cac:ReceiverParty>
<cac:DocumentResponse>
<cac:Response>
<cbc:ResponseCode>030</cbc:ResponseCode>
<cbc:Description>Acuse de recibo de Factura Electrónica de Venta</cbc:Description>
</cac:Response>
<cac:DocumentReference>
<cbc:ID>FV0000</cbc:ID>
<cbc:UUID schemeName="CUFE-SHA384">000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000</cbc:UUID>
<cbc:DocumentTypeCode>01</cbc:DocumentTypeCode>
</cac:DocumentReference>
<cac:IssuerParty>
<cac:Person>
...
</cac:Person>
</cac:IssuerParty>
</cac:DocumentResponse>
</ApplicationResponse>

<ApplicationResponse
xmlns="urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2"
xmlns:sts="dian:gov:co:facturaelectronica:Structures-2-1"
xmlns:xades="http://uri.etsi.org/01903/v1.3.2#"
xmlns:xades141="http://uri.etsi.org/01903/v1.4.1#"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<ext:UBLExtensions>
...
</ext:UBLExtensions>
<cbc:UBLVersionID>UBL 2.1</cbc:UBLVersionID>
<cbc:CustomizationID>1</cbc:CustomizationID>
<cbc:ProfileID>DIAN 2.1: ApplicationResponse de la Factura Electrónica de Venta</cbc:ProfileID>
<cbc:ProfileExecutionID>1</cbc:ProfileExecutionID>
<cbc:ID>0000000000000000000</cbc:ID>
<cbc:UUID schemeID="1" schemeName="CUDE-SHA384">000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000</cbc:UUID>
<cbc:IssueDate>2026-06-30</cbc:IssueDate>
<cbc:IssueTime>15:14:00-05:00</cbc:IssueTime>
<cbc:Note>OK</cbc:Note>
<cac:SenderParty>
...
</cac:SenderParty>
<cac:ReceiverParty>
...
</cac:ReceiverParty>
<cac:DocumentResponse>
<cac:Response>
<cbc:ResponseCode>032</cbc:ResponseCode>
<cbc:Description>Recibo del bien y/o prestación del servicio</cbc:Description>
</cac:Response>
<cac:DocumentReference>
<cbc:ID>FV0000</cbc:ID>
<cbc:UUID schemeName="CUFE-SHA384">000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000</cbc:UUID>
<cbc:DocumentTypeCode>01</cbc:DocumentTypeCode>
</cac:DocumentReference>
<cac:IssuerParty>
<cac:Person>
...
</cac:Person>
</cac:IssuerParty>
</cac:DocumentResponse>
</ApplicationResponse>

<ApplicationResponse
xmlns="urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2"
xmlns:sts="dian:gov:co:facturaelectronica:Structures-2-1"
xmlns:xades="http://uri.etsi.org/01903/v1.3.2#"
xmlns:xades141="http://uri.etsi.org/01903/v1.4.1#"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<ext:UBLExtensions>
...
</ext:UBLExtensions>
<cbc:UBLVersionID>UBL 2.1</cbc:UBLVersionID>
<cbc:CustomizationID>1</cbc:CustomizationID>
<cbc:ProfileID>DIAN 2.1: ApplicationResponse de la Factura Electrónica de Venta</cbc:ProfileID>
<cbc:ProfileExecutionID>1</cbc:ProfileExecutionID>
<cbc:ID>0000000000000000000</cbc:ID>
<cbc:UUID schemeID="1" schemeName="CUDE-SHA384">000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000</cbc:UUID>
<cbc:IssueDate>2026-06-30</cbc:IssueDate>
<cbc:IssueTime>15:14:00-05:00</cbc:IssueTime>
<cbc:Note>OK</cbc:Note>
<cac:SenderParty>
...
</cac:SenderParty>
<cac:ReceiverParty>
<cac:PartyTaxScheme>
...
</cac:PartyTaxScheme>
<cac:Contact>
...
</cac:Contact>
</cac:ReceiverParty>
<cac:DocumentResponse>
<cac:Response>
<cbc:ResponseCode>033</cbc:ResponseCode>
<cbc:Description>Aceptación expresa</cbc:Description>
</cac:Response>
<cac:DocumentReference>
...
</cac:DocumentReference>
</cac:DocumentResponse>
</ApplicationResponse>

Este archivo XML, que contiene la estructura del acuse comercial, debe enviarse una vez que la factura ya se encuentre registrada en Inbox, remitiéndose a la misma casilla de correo de recepción.

Una vez que el acuse ingrese por este medio, podrá visualizarse como un archivo adjunto dentro de la sección de Adjuntos en la previsualización del documento, de la siguiente manera:

4.2. Emitir manualmente el acuse comercial para estos documentos.

Estos eventos comerciales se pueden generar manualmente desde dos puntos diferentes de Inbox que exploraremos a continuación:

4.2.1. Botón Opciones (Documentos Recibidos)

**1.**Para acceder a esta opción y generar manualmente el acuse comercial que se requiere para el o los documentos, en inbox se debe seleccionar por medio del checkbox o selector los documentos que se requieren gestionar.

**2.**Ahora, se deberá seleccionar el boton “Opciones” y buscar la sección “Acuse comercial” que se encuentra ubicado: Inbox / Bandeja Recibidos / Boton Opciones / Sección: mensaje receptor, Dentro de este menú, encontrará las siguientes opciones de Acuse Comercial:

Al ingresar a a la opción del acuse comercial

**3.**Seleccione el estado de aprobación del documento. Este puede ser aprobado, aprobado parcialmente o rechazado.

**4.**Ingrese el detalle del mensaje que se mostrará en el XML del acuse generado una vez que este se apruebe.

**5.**Ingrese los correos a los que se enviará una copia del acuse.

**6.**Presione Enviar para enviar la solicitud a la Entidad Tributaria.

Al relacionar toda la información para realizar el mensaje receptor seguido del botón Enviar, este evento se mostrará dentro de la vista previa del documento en el apartado de notas

y se mostrará el XML del evento enviado a la Entidad Tributaria en la parte de adjuntos como se muestra a continuación:

---

3.2.2. Aplicar acuses comerciales desde la previsualización del documento

Este proceso también se puede hacer desde la vista previa del documento.

Al seleccionar Mensaje Receptor desde el menú Acuse comercial. Después, llene el formulario mencionado en el literal a de esta sección.

3.2.3. Iconografía según el acuse comercial

Una vez que se terminó el proceso, se mostrará un cambio en el estado del documento de acuerdo con el estado de aprobación seleccionado durante la emisión del mensaje.

1. Se muestra el estado Aceptado cliente luego de haber seleccionado aprobado en el estado del documento dentro del formulario del mensaje receptor
2. El estado cambia a Rechazado cuando se seleccionó rechazado en el estado de aprobación del documento dentro del formulario de mensaje receptor.
3. Aceptado parcialmente se muestra una vez que se seleccionó aprobado parcialmente en el llenado del formulario del mensaje receptor.
4. Asimismo, el ícono de documentos adjuntos se mostrará en color gris oscuro para indicar existe un adjunto del mensaje receptor.

Además, se mostrará la nota del evento y el archivo adjunto con el XML del proceso en la vista previa del documento

El mensaje receptor se enviará a la cuenta de correo relacionada en el proceso de realizar el  acuse y se mostrará la siguiente notificación:

aviso

Para obtener más detalles sobre la ejecución de acuses comerciales desde la API disponibles en esta sección, consulte el Manual de Inbox y API.

---

5. CONSULTA DE DOCUMENTOS RECIBIDOS DESDE GOSOCKET

Una vez que los documentos fueron procesados por el servicio de recepción, estos podrán ser consultados desde el portal de Gosocket en el apartado Inbox/Recibidos. **

En este apartado se muestra la siguiente pantalla:

**1.**Sección de filtros para optimizar el resultado de la búsqueda. **

**2.**Control de orden de despliegue, con el que podrá modificar la forma en que se presentarán los resultados de la búsqueda. **

**3.**Lista de opciones vinculadas con la exportación, respuestas comerciales y movimientos internos de los Comprobantes Electrónicos. **

**4.**Sección de visualización con el detalle del resultado de la búsqueda e iconografía representativa de los cambios de estado más relevantes. **

aviso

* Para más información sobre estos puntos, consulte la documentación de Inbox.**

Una vez realizada la búsqueda de documentos en el grid principal se mostrará la lista de documentos recibidos que cumplieron con los criterios de búsqueda establecidos, en este grid además de información relevante del documento se puede observar el estado del documento.

**1.**Validación de la entidad tributaria.

**2.**Validación de distribución.

**3.**Validación estado Smart Supply.

**4.**Validación Mensaje Receptor

En la columna de estado (1) se mostrará el resultado de las validaciones aplicadas, tal como se explicó en el apartado Proceso de Recepción de un XML.

Icono	Estado	Validación
	VALIDADA	Documento aprobado por la ET
	RECHAZADA*	Documento rechazado por la ET
	No Disponible en ET	Documento no existe en la ET
❗	ERROR*	Documento Rechazado o excepción interna por Gosocket
	Error de Firma	Documento con error de firma
	Error de esquema	Documento con error de esquema
	Error de esquema pero continua el flujo *	El XML presenta error de esquema, pero si se activa la configuración, esta opción permite continuar el flujo de recepción.

Nota: Al dar clic en el documento se abrirá la previsualización del documento donde podrá revisar las notas relacionadas al motivo de rechazo.

* Nota: para el caso en el que el documento quede en estado “ERROR”, el usuario podrá reprocesarlo a través de las acciones, con el objetivo de realizar nuevamente las validaciones de esquema, firma o ET. Este proceso se explica a detalle en el apartado Reprocesamiento.

* Nota: Configuración especial: El XML presenta error de esquema, pero si se activa la configuración, esta opción permite continuar el flujo de recepción:

Esta característica se puede activar de forma independiente por cada empresa. Su objetivo es que, si se detecta un error de esquema en el XML al recibir el documento en Gosocket, el detalle del error puntual se registrará automáticamente en la sección de "Notas" del documento.

A pesar de este hallazgo, el documento continuará con su flujo normal hacia las siguientes validaciones de recepción, tales como la verificación de la firma y de la entidad tributaria.

El documento quedará en Inbox de la siguiente manera:

En Gosocket el documento quedará en estado Validado ET con error esquema y se mostrará el icono naranja, así

Para obtener más detalles sobre cómo configurar esta funcionalidad, consulte el siguiente apartado: Configuración XML presentan errores de esquema y continua el flujo de recepción. / XML Configuration Presents Schema Errors and Reception Flow Continues