Chile: 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 Chile

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

aviso

Validación de firma avanzada:

En el país de Chile NO se realiza validación de firma, pero Gosocket tiene proceso opcional llamado “Validación de firma avanzada” y tiene como objetivo validar ante la Entidad Tributaria la integridad de la firma del documento y se puede activar por medio de una solicitud al equipo de Producto.

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. Cuando el documento tiene el estado Anulado en la ET

Si el documento existe y el estado del documento es Anulado en la Entidad Tributaria, su estado en inbox será ANULADO y se le asignara el icono .

m. 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:

n. 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

o. 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)
• Si existe el documento, pero este tiene un estado Anulado (Para más detalle en el literal L)

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 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.

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”
• 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.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.

información

Documentos ensobretados:

Los documentos que llegan ensobretados (es decir, más de dos documentos en un mismo paquete) donde, se incluyen el documento original junto con su respectiva firma. No obstante, el nodo "Certificate" se declara una única vez para todos los documentos contenidos en el sobre.

Posteriormente, la plataforma de Gosocket realiza un proceso interno: cuando el sistema separa los documentos ensobretados y genera un nuevo XML para cada uno, añade de forma automática el nodo "Certificate" a cada archivo individual.

De esta manera, se puede realizar la validación de firma a todos los documentos tributarios.

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:

• Boleta Electrónica
• Boleta No Afecta o Exenta Electrónica
• Factura de Compra Electrónica
• Factura de Exportación Electrónica
• Factura Electrónica
• Factura No Afecta o Exenta Electrónica
• Guía de Despacho Electrónica
• Liquidación Factura Electrónica
• Nota de Crédito de Exportación Electrónica
• Nota de Crédito Electrónica
• Nota de Débito de Exportación Electrónica
• Nota de Débito Electrónica
• Boleta de Honorarios Electrónica*

aviso

Nota: Para la recepción y el tratamiento de la Boleta de Honorarios Electrónica, tenga en cuenta los siguientes puntos:

• Este documento se emite únicamente desde la plataforma del Servicio de Impuestos Internos (SII).
• Para que podamos recibir la boleta de honorarios electrónica en la bandeja de Recibidos del Inbox de Gosocket, el cliente debe configurar la casilla de intercambio de GS directamente en la plataforma del SII.
• A diferencia de otros documentos, a la Boleta de Honorarios no se le realizan validaciones de Esquema, ni validación ante la Entidad Tributaria.

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): cl_ms_sbx@inbound.gosocket.com
• Productivo: cl@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:

• Boleta Electrónica
• Boleta No Afecta o Exenta Electrónica
• Factura de Compra Electrónica
• Factura de Exportación Electrónica
• Factura Electrónica
• Factura No Afecta o Exenta Electrónica
• Guía de Despacho Electrónica
• Liquidación Factura Electrónica
• Nota de Crédito de Exportación Electrónica
• Nota de Crédito Electrónica
• Nota de Débito de Exportación Electrónica
• Nota de Débito Electrónica
• Boleta de Honorarios Electrónica*

aviso

Nota: Para la recepción y el tratamiento de la Boleta de Honorarios Electrónica, tenga en cuenta los siguientes puntos:

• Este documento se emite únicamente desde la plataforma del Servicio de Impuestos Internos (SII).
• Para que podamos recibir la boleta de honorarios electrónica en la bandeja de Recibidos del Inbox de Gosocket, el cliente debe configurar la casilla de intercambio de GS directamente en la plataforma del SII.
• A diferencia de otros documentos, a la Boleta de Honorarios no se le realizan validaciones de Esquema, ni validación ante la Entidad Tributaria.

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. 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 existen 5 acuses comerciales a los documentos recibidos:

a. Acuse de recibo de la Factura Electrónica de Venta.Acuse de recibo

b. Recibimiento de los bienes

c. Aceptado

d. Aceptado (Discrepancias)

e. 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:

4.1. Recibir los acuses comerciales por la casilla de intercambio

4.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: acuse comercial, Dentro de este menú, encontrará las siguientes opciones de Acuse Comercial:

Al ingresar a cualquiera de los acuses se mostrará una ventana emergente con un formulario para dejar alguna observación. También podrá ingresar un correo electrónico adicional para que llegue una copia del Acuse y, en el caso del acuse de reclamo, una lista con los tipos de rechazo.

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:

i. Evento de Acuse de Recibo o Recibimiento de los bienes

Al seleccionar Acuse de Recibo o Recibimiento de los bienes, se muestra la ventana emergente que vemos a continuación:

a. Tipo de acuse: se mostrará la información del tipo de acuse que se seleccionó previamente.

b. Recinto: ingrese el recinto por el cual se emitirá el acuse de recibimiento de los bienes. Para el caso del acuse de recibo, será necesario ingresar una descripción del acuse en este campo.

c. Estado de aprobación: se muestra el tipo de aprobación que se mostrará en el acuse de recibo.

d. Enviar copia a: Redacte el correo al que se enviará la notificación de que generó el acuse de recibo.

e. Al terminar, presione Enviar.

ii. Evento de Aceptado - Aceptado (Discrepancias) - rechazado

2.*Aceptado: Produce un acuse de aceptado.

3.*Aceptado (Discrepancias): Se genera un acuse de recibo de aceptación del documento con algunos ajustes por hacer.

4.*Rechazado: Emite un acuse de rechazo del documento.

Una vez que seleccionó alguna de estas opciones, se mostrará el siguiente formulario.

1.*Tipo de acuse: se mostrará la información del tipo de acuse que se seleccionó previamente.

2.*Descripción: ingrese un enunciado que explique la selección del tipo de acuse.

3.*Estado de aprobación:  se muestra el tipo de aprobación que se mostrará en el acuse comercial. En el caso del Rechazo (Reclamo), el estado de aprobación mostrará una lista de la que podemos elegir el motivo del rechazo.

4.*Enviar copia a: Redacte el correo al que se enviará la notificación de que generó el acuse de recibo.

**5.**Al terminar, presione Enviar.

Este evento se verá reflejado en 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:

Asimismo, el Evento de Notificación - Recepción se mostrará en la iconografía de estado del documento.

---

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

Estos eventos se pueden generar también desde la previsualización del documento de Inbox que exploraremos a continuación.

Esta acción también se puede realizar desde la vista previa del documento a través del botón Acuse comercial.

4.2.3. Iconografía según el acuse comercial

De acuerdo con el acuse comercial asignado previamente, el documento puede mostrar alguno de los siguientes íconos al consultarlo desde Recibidos:

1. Acuse de recibo del documento: Este estado informa acerca de la emisión del acuse sobre un documento que se puede mostrar en dos escenarios:

a.   Gris, que se mostrará cuando el documento aún no tiene un acuse comercial.

b.   Verde, que indica que el acuse se emitió satisfactoriamente.

2. Evento de recibo del bien o servicio: Este estado muestra el evento de Recibo del bien o Servicio de Mercadería, en caso de no contar con este evento, el ícono estará en color gris.

3. Aceptación o reclamo del documento:  Para la aceptación bien sea expresa o tácita se mostrará un ícono con una mano hacia arriba en color verde, en caso de ser rechazado se mostrará un ícono con una mano hacia abajo en color rojo, en caso de no contar con este evento, la mano estará en color gris.

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. FUNCIONALIDAD PARA CLIENTES EN CHILE QUE SOLO REQUIEREN CONTRATAR LA RECEPCIÓN

El objetivo de esta funcionalidad está diseñado para aquellas empresas en Chile que requieren contratar únicamente el servicio de recepción de documentos con Gosocket, manteniendo la emisión con un proveedor tecnológico distinto.

Esta opción permite configurar un correo electrónico (o casilla) del emisor al cual se reenviarán automáticamente los eventos comerciales.

La funcionalidad se configura así:

• Configuración en el SII: El cliente debe configurar la casilla de intercambio de Gosocket directamente en la plataforma del Servicio de Impuestos Internos (SII).
• Configuración en la Plataforma Gosocket: Dentro de la sección Configuraciones, acceda a la pestaña Políticas y realice lo siguiente:

1. Ingresar a la opción del  perfil del  usuario de Inbox.
2. Seleccionar la opción Configuraciones
3. Activar el check "Habilitar solo para Recepción".
4. Ingresar el Correo de Reenvío: Se debe registrar el correo electrónico al cual se deben reenviar los eventos que lleguen a la casilla de intercambio. Este correo debe corresponder a la casilla del proveedor de emisión del cliente, permitiendo así que dicho proveedor reciba y procese los eventos relacionados con los documentos emitidos.
5. Dar clic en el  botón Guardar.

6. 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.**Acuse de recibo.

**5.**Acuse de recibo del bien o servicio.

**6.**Acuse Aceptación o reclamo del documento.

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
	ANULADO	Documento anulado en la ET
	Error de Firma	Documento con error de firma
	Errode 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

---