Panamá: 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 Panamá
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.
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
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 firma
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. 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 |
|---|---|---|
| h | Documento tiene error de esquema | |
| i | Documento tiene error de firma | |
| j | Documento quedó Aceptado por 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 de firma o Error de esquema .
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 de Operación Interna
- Factura de Importación
- Factura de Exportación
- Nota Crédito referente a una o varias FE
- Nota Débito referente a una o varias FE
- Nota Crédito Genérica
- Nota Débito Genérica
- Factura de Zona Franca
- Reembolso
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):
pa_ms_sbx@inbound.gosocket.com - Productivo:
pa@recepcionprd.gosocket.net
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 de Operación Interna
- Factura de Importación
- Factura de Exportación
- Nota Crédito referente a una o varias FE
- Nota Débito referente a una o varias FE
- Nota Crédito Genérica
- Nota Débito Genérica
- Factura de Zona Franca
- Reembolso
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.
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.
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.
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. ACUSES COMERCIALES
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, en Panamá existe el envío del acuse comercial, denominado Manifestación del receptor, el cual se genera para los documentos recibidos y tiene como finalidad informar a la Entidad Tributaria lo siguiente:
a. Confirmación de los datos de la operación.
b. Confirmación de la operación.
c. Confirmación de la transacción.
d. Cancelación de negocio.
e. Desconocimiento de la operación.
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 se pueden generar también desde la previsualización del documento de Inbox que exploraremos a continuación.
4.2.1. Aplicar acuses comerciales desde la previsualización del documento
Esta acción se puede realizar desde la vista previa del documento a través del botón Manifestación del receptor.
Al ingresar a cualquiera de los Acuses se mostrará una ventana emergente con un formulario para dejar alguna observación.
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:
y en la parte de adjuntos como se muestra a continuación:
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. **
* 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.
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 |
| * | 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 de esquema o rechazo de firma.
* 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