Chile: Reception of documents (MS)

1. XML RECEPTION PROCESS

This process allows receiving different types of documents from customers and suppliers through the channels offered by Gosocket. Once received, both the issuer and the recipient will be able to view the documents in the Inbox Received tray, along with their respective graphic representation and attached files.

Likewise, our system performs a series of automatic validations to ensure that the structure and integrity of the information strictly comply with the requirements of the tax authorities.

The following image describes, step by step, the document reception flow within the Inbox platform:

Chile reception process

1. Methods for sending the XML document in Gosocket:

The supplier has the option of sending the XML document to the Gosocket platform in three ways:

a. The supplier manually uploads the XML file using Gosocket's Upload option. The requirements and conditions for this process are detailed in the section Manual upload.

b. The supplier sends the XML document through Gosocket's exchange mailbox . The requirements and conditions for this process are detailed in the section Exchange mailbox.

c. The supplier uploads the XML document through Gosocket's Reception API. The requirements and conditions for this process are detailed in the section Reception APIs.

info

Note: When using any of the following document reception channels:

• Exchange mailbox
• Manual XML upload (Upload option)
• Reception API

The system will automatically run the schema and signature validations, as well as the corresponding validation with the Tax Authority (TA).

2. Reception and validation of documents in Gosocket

The Gosocket portal downloads and processes the XML. When it is a tax document, it enters a reception validation process.

3. Document schema validation

First, a schema validation is performed on the XML document to ensure it complies with the format established by the tax authority. Depending on the result of this validation, the process can lead to one of the following scenarios:

d. Failed: The document does not comply with the fiscal format, the document reception flow will be stopped due to the schema error, it will be registered in Gosocket with Schema Error status, and the icon will be shown in the interface, and the reason for the rejection will be detailed in the document's notes, as follows:

Schema error icon in inbox

Document detail Notes section - Schema Error

Detail of the XML processing for the schema error

e. Successful: If the XML schema validation is correct, the document will continue with the reception flow.

Document detail Notes section - Successful schema validation

info

Special configuration: The XML has a schema error, but if the configuration is enabled, this option allows the reception flow to continue:

This feature can be enabled independently for each company. Its purpose is that, if a schema error is detected in the XML when the document is received in Gosocket, the specific error detail will be automatically recorded in the document's "Notes" section.

Despite this finding, the document will continue with its normal flow toward the following reception validations, such as the signature and tax authority verification.

The document will remain in Inbox as follows:

• In Gosocket, the document will remain in Validated ET with schema error status and the orange icon will be shown, as follows:

For more details on how to configure this feature, see the following section: XML Configuration Presents Schema Errors and Reception Flow Continues

4. Electronic signature validation of the document

warning

Advanced signature validation:

In Chile, signature validation is NOT performed, but Gosocket has an optional process called “Advanced signature validation” whose purpose is to validate the integrity of the document's signature with the Tax Authority, and it can be enabled by submitting a request to the Product team.

5.Validation of the document with the Tax Authority

Third, the query validation with the Tax Authority is performed. Several outcomes can result from this validation:

h. Document has an internal exception from Gosocket ❗

When the document's validation query is performed with the Tax Authority and Gosocket is unable to connect to the TA's service, or there are communication errors with the service, the document changes its status to ERROR and is assigned the icon ❗.

Error icon in inbox: No communication with the TA.

Document detail Notes section - Document validation with the TA with communication error.

i. At this point in the process, when the document does exist in the tax authority , two outcomes can result:

• If the document exists, but it has a Rejected status (For more details, see item j)
• If the document exists, but it has an Accepted status (For more details, see item k)

j. Document Rejected by the Tax Authority

If the document exists in the TA, but there is some reason for rejection at the Tax Authority, its status will be Rejected and it will be assigned the icon .

Rejected icon in inbox: Document validation with the TA rejected

Document detail Notes section - Document validation with the TA rejected

k. Document Accepted by the Tax Authority

If the result of the previous validations (Schema and Signature) is satisfactory and the query with the tax authority is successful, the document will be registered in Gosocket with Accepted status. In the interface, this status will be identified with a green checkmark icon.

Accepted icon in inbox: Successful document validation with the TA

Document detail Notes section - Successful document validation with the TA

L. When the document has Voided status in the TA

If the document exists and its status is Voided at the Tax Authority, its status in inbox will be CANCELLED and it will be assigned the icon .

m. Automatic retries when the document has Not Available status in the TA .

At this stage of the process, when the document does not exist in the Tax Authority, it is indicated that the received document is not registered with the TA. In this scenario, the following actions are performed on the document:

• In Gosocket, the document will remain with the Not Available in ET status and will be assigned the corresponding icon .

• An automatic retries process will be triggered, which consists of performing multiple queries to the Tax Authority to check whether the document changes to a status other than Not Available in ET. If a different status is obtained during any of these retries, the document will automatically update both its status and its corresponding icon.

• If, after completing all the retries, the document is still not available in the Tax Authority, it will keep the Not Available in ET status and the corresponding icon .

• The current retry parameter is 30 attempts in 1 hour (the query retry is performed every 2 minutes).

When the document is received and the query retries with the TA are performed, the following message is shown in the Notes section:

and within the document detail, the “TAX-CHECK” code will indicate that the validation with the TA has started:

Once the automatic retries have been exhausted (approximately one hour later), the final status of the document with the TA will be displayed, as follows:

and the document detail will show the message:

“Integrated Query with the TA: Does not exist. 30 attempts were made. Manual reprocessing was performed.”

and another message will be shown on the next line: “The maximum number of retries for the status query with the TA was reached”, as follows:

and following these retries, two outcomes can result:

n. If after the 30 attempts the document still cannot be found, it will remain permanently in Not Available in ET status, showing the following icon in the Inbox.

Rejected icon in inbox: Document validation with the TA r

o. If during these retries the document is found in the TA, its status is updated, the process continues, and two outcomes can result:

• If the document exists, but it has a Rejected status (For more details, see item j)
• If the document exists, but it has an Accepted status (For more details, see item k)
• If the document exists, but it has a Voided status (For more details, see item L)

6. Icons in inbox for the reception validation results

Finally, both the issuer and the recipient will be able to view the results of the XML document validations in Inbox, as follows:

No.	Status	Icon in the inbox interface
o	Document has a schema error
p	Document has a signature error
q	Communication error with the Tax Authority
r	Document was Accepted by the Tax Authority
s	Document was Rejected by the Tax Authority
t	Document not available or does not exist in the Tax Authority

7. Issuance of commercial acknowledgments

Once the document has been received and validated, the commercial or mercantile acknowledgments deemed necessary can be issued from the inbox platform, or otherwise sent through the exchange mailbox. This is explained in more detail in the section Commercial acknowledgments.

---

2. MANUAL REPROCESSING OF DOCUMENTS

Additionally, a button was implemented in Inbox that allows tax documents with “ERROR” ❗ status, or “Not Available in ET” or Schema Error status to be manually reprocessed.

info

Note: This option only allows reprocessing documents that were sent through the exchange mailbox, the reception API, or manual upload (upload).

This reprocessing option can be found in the following path, as applicable:

• Inbox/Received/Options/Actions/Reprocess document without validating schema.
• Inbox/Received/Options/Actions/Reprocess document.

Accompanied by a selector that, as its name indicates, will allow selecting an Electronic Document or a set of them independently.

Next, a pop-up window will be displayed in which the user must confirm that they want to revalidate the previously selected documents.

Once the reprocessing has been generated, a banner will be shown at the top of the page indicating that the document(s) were sent for reprocessing:

and finally, for any of the three types of reprocessing generated through this option, the notes section will indicate:

• It records the email of the user who performed the document reprocessing.
• It generates a note “Document processed without schema validation”
• The document continues the reception validation flow.

This button allows reprocessing the different validations of the reception process:

2.1. Reprocess document without validating schema:

Allows the document to go through the reception validations without taking the schema validation into account; however, when the document is selected and this reprocessing without schema validation is applied, the system:

• Records the email of the user who performed the document reprocessing.
• Generates a note “Document processed without schema validation”.
• The document continues the reception validation flow.

2.3. Reprocess document:

Allows reprocessing the document from scratch and performs the reception validations again without skipping any validation; however, when the document is selected and this reprocessing is applied, the system:

• Records the email of the user who performed the document reprocessing.
• Performs the reception validations without skipping any of them.

---

3. METHODS FOR SENDING AN XML

Currently, there are three methods for receiving documents into the system:

• Manual upload: Importing the XML file using the Upload option in Gosocket.
• Exchange mailbox: Automated inbound flow through the exchange mailbox.
• Reception API: Connection via API for integrated processing.

info

Enveloped documents:

Documents that arrive enveloped (that is, more than two documents in the same package) include the original document along with its respective signature. However, the "Certificate" node is declared only once for all the documents contained in the envelope.

Subsequently, the Gosocket platform performs an internal process: when the system separates the enveloped documents and generates a new XML for each one, it automatically adds the "Certificate" node to each individual file.

This way, signature validation can be performed on all tax documents.

3.1. Manual XML upload through Gosocket Upload

Gosocket has a tool within the Inbox platform that allows the supplier to directly upload the XML file of their documents.

• Access path: Main menu > Upload > Manual Upload.

From this section, the user can select the XML file from their device's file explorer or, if preferred, drag and drop it directly into the interface.

Once the document is received, the solution automatically starts the processing and validation flow.

Once the XML file is received through the manual upload option, the following will be identified:

a. How many XML files were received in total, how many were processed successfully, and how many have errors.

b. By clicking the “Details” button, a popup will be displayed with the “Error Details” identifying the possible errors that the XML file manually uploaded through this option may contain; otherwise, if the document has no errors, a detail will be shown indicating that it was successfully uploaded to the Gosocket platform:

c. Finally, the document will be displayed in the Inbox received tray, with all validations completed.

3.1.1. Considerations for manual XML upload

• Up to 100 XML files can be uploaded in a single upload.
• Schema, signature, and Tax Authority validations will be performed.
• The tax documents stipulated by the Tax Authority must be sent in XML format.

The tax documents that can be received are:

• Electronic Receipt
• Non-Taxable or Exempt Electronic Receipt
• Electronic Purchase Invoice
• Electronic Export Invoice
• Electronic Invoice
• Non-Taxable or Exempt Electronic Invoice
• Electronic Dispatch Guide
• Electronic Invoice Settlement
• Electronic Export Credit Note
• Electronic Credit Note
• Electronic Export Debit Note
• Electronic Debit Note
• Electronic Fee Receipt*

warning

Note: For the reception and handling of the Electronic Fee Receipt, please take into account the following points:

• This document is issued exclusively from the Internal Revenue Service (SII) platform.
• In order for us to receive the electronic fee receipt in the Inbox Received tray of Gosocket, the customer must configure the GS exchange mailbox directly in the SII platform.
• Unlike other documents, the Fee Receipt does not undergo validations of Schema, nor validation with the Tax Authority.

3.2. Exchange mailbox

This is the process by which the supplier sends its XML files through an email mailbox. Each country has specific addresses assigned according to the working environment.

The mailboxes that must be used, according to the environment, are:

• Sandbox (Testing): cl_ms_sbx@inbound.gosocket.com
• Production: cl@recepcionprd.gosocket.net

info

Note: If a customized exchange mailbox is needed for a customer, it must be escalated to the commercial team, since this request generates an additional cost.

3.2.1. Considerations for the exchange mailbox

It is important to keep the following points in mind when sending documents, as this will prevent them from being rejected by the application.

a. The tax documents that can be sent through the exchange mailbox are:

• Electronic Receipt
• Non-Taxable or Exempt Electronic Receipt
• Electronic Purchase Invoice
• Electronic Export Invoice
• Electronic Invoice
• Non-Taxable or Exempt Electronic Invoice
• Electronic Dispatch Guide
• Electronic Invoice Settlement
• Electronic Export Credit Note
• Electronic Credit Note
• Electronic Export Debit Note
• Electronic Debit Note
• Electronic Fee Receipt*

warning

Note: For the reception and handling of the Electronic Fee Receipt, please take into account the following points:

• This document is issued exclusively from the Internal Revenue Service (SII) platform.
• In order for us to receive the electronic fee receipt in the Inbox Received tray of Gosocket, the customer must configure the GS exchange mailbox directly in the SII platform.
• Unlike other documents, the Fee Receipt does not undergo validations of Schema, nor validation with the Tax Authority.

b. The tax documents stipulated by the Tax Authority must be sent in XML.

c. They can be sent individually or as several XML files in the same email.

d. Several XML files can be sent compressed in a file, and only the .zip extension is allowed.

e. The XML or compressed (.zip) files must be attached to the email of the mailbox provided by Gosocket.

f. Attached documents can be sent, such as the invoice PDF or other files as required.

g. The maximum allowed size for an email that includes XML and PDF files is 20MB.

h. The solution can process the graphic representation PDF, if included, and attached documents that arrive at the mailbox, which, once received, are stored and associated with their corresponding document, allowing download within Inbox.

The process works as follows:

• If an XML document arrives at the exchange mailbox along with an additional PDF file with the same name, for example: Invoice12345.xml and Invoice12345.pdf, it is understood that the .pdf file is the graphic representation of the DTE, so it is synced that way in Gosocket and will be available for viewing.
• If an XML document arrives at the mailbox with more than one attachment of any extension, they are associated as attached documents.

warning

Note: If there are PDF files with a name different from the XML, they will be considered as attached documents.

• For sending attachments, it is recommended to send each DTE with its attachments separately, since if more than one XML document arrives, the graphic representation will only be stored as long as the PDF file has the same name as its corresponding XML; the rest of the attached files will not be processed since there is no way to know which document to associate them with.
• Attachments can also be associated after the XML is sent; for example, if the XML is sent without attachments, another email with attached documents (PDF, Excel, Word, etc.) can be sent afterward, and these will be associated with the previously sent document, as long as the second email also includes the XML.

3.3. Reception APIs

For the document reception process, Gosocket offers two APIs that allow sending XML to the Gosocket platform:

3.3.1. UploadZipDocument:

This API allows sending a request that includes one or several XML and PDF files to Gosocket, packaged together in a compressed file (.zip). Once received, the system processes the document, generates the corresponding record, and securely stores it on the platform.

a. Tracking Management

To perform detailed end-to-end tracking of the PDF processing, from when the PDF enters the platform through the exchange mailbox until the supplier sends the XML and PDF to Gosocket, this entire process is assigned two unique identifiers called "externalId" and "batchId".

b. Upload and storage

The API manages the reception of the .zip file, which must contain the PDF and its corresponding XML in Gosocket's native format for proper integration into the ecosystem.

This API allows the reception, processing, and storage of electronic documents on the Gosocket platform.

c. Post-storage processing actions

Once the document has been successfully stored in Inbox, the following actions can be performed:

• Reception validations (Automatic): Technical verification of standards compliance, including:

o   Schema validation.

o   Integrity of the document's Electronic Signature.

o   Validations with the corresponding Tax Authority: Indicates whether the document was accepted, rejected, or has validation errors from the regulatory entity after the fiscal validation.

• Receiver Message (Automatic): Application of receiver message events according to the tax authority's current regulations.
• Smart Supply Validations (On-demand configuration): Application of logical rules and approval flows configured in the Smart Supply module.
• File Distribution (On-demand configuration): Once the document has been processed on the Gosocket platform, and based on the previously configured distribution rules, the system performs the automated transfer of the files to the configured technical destinations. This feature allows integration with various environments, such as:

o   Windows Servers.

o   File transfer protocols (SFTP / FTP).

o   Automated sending via email.

warning

You can find the configuration details of the Reception API at the following link: API Reception.zip - Generic

3.3.2. SendDocumentToUpload:

This API allows sending a request that includes a single XML to Gosocket. Once received, the system processes the document, generates the corresponding record, and securely stores it on the platform.

a. Upload and storage

The API manages the reception of the file in XML format for its integration into the Gosocket ecosystem:

• Ingestion: Uploads the document directly into the Inbox module of Gosocket through the  endpoint: POST - SendDocumentToUpload
• Persistence: Ensures the storage of the XML file on the platform's servers for later management.

b. Tracking Management

The successful execution of the API generates a unique identifier called trackId. This value is returned in the response and is essential for:

• Performing detailed tracking of the processing status.
• Querying the upload result through the endpoint: GET- GetDocumentUploadStatus

c. Post-storage processing actions

Once the document has been successfully stored in Inbox, the following actions can be performed:

• Reception validations (Automatic): Technical verification of standards compliance, including:

o   Schema validation.

o   Integrity of the document's Electronic Signature.

o   Validations with the corresponding Tax Authority: Indicates whether the document was accepted, rejected, or has validation errors from the regulatory entity after the fiscal validation.

• Receiver Message (Automatic): Application of receiver message events according to the tax authority's current regulations.
• Smart Supply Validations (On-demand configuration): Application of logical rules and approval flows configured in the Smart Supply module.
• File Distribution (On-demand configuration): Once the document has been processed on the Gosocket platform, and based on the previously configured distribution rules, the system performs the automated transfer of the files to the configured technical destinations. This feature allows integration with various environments, such as:

o   Windows Servers.

o   File transfer protocols (SFTP / FTP).

o   Automated sending via email.

warning

You can find the configuration details of the Reception API at the following link: Reception API

---

4. COMMERCIAL ACKNOWLEDGMENTS

The commercial acknowledgment aims to validate tax documents with the Tax Authority, and as a result, we will have a status change within our received documents tray in the Gosocket Inbox.

Through the use of these events, the recipient reports the receipt, acceptance, or rejection of each document.

These events can be generated from two different points in Inbox, which we will explore below.

There are currently 5 commercial acknowledgments for received documents:

a. Acknowledgment of receipt of the Electronic Sales Invoice.Acknowledgment of receipt

b. Receipt of the goods

c. Accepted

d. Accepted (Discrepancies)

e. Rejected

Once the documents have been received in inbox and have passed the reception validations, Gosocket allows applying the commercial acknowledgments as follows:

4.1. Receive commercial acknowledgments through the exchange mailbox

4.2. Manually issue the commercial acknowledgment for these documents.

4.1. Reception of commercial acknowledgments through the exchange mailbox

To receive commercial acknowledgments through the exchange mailbox, the file must strictly comply with the specific structure required by the TA and be in XML format.

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

This XML file, which contains the structure of the commercial acknowledgment, must be sent once the invoice is already registered in Inbox, sending it to the same reception mailbox.

Once the acknowledgment enters through this channel, it can be viewed as an attached file within the Attachments section in the document preview, as follows:

4.2. Manually issue the commercial acknowledgment for these documents.

These commercial events can be generated manually from two different points in Inbox, which we will explore below:

4.2.1. Options Button (Received Documents)

**1.**To access this option and manually generate the commercial acknowledgment required for the document(s), in inbox you must select, using the checkbox or selector, the documents you need to manage.

**2.**Now, you must select the “Options” button and look for the “Commercial acknowledgment” section, which is located at: Inbox / Received Tray / Options Button / Section: commercial acknowledgment, Within this menu, you will find the following Commercial Acknowledgment options:

When entering any of the acknowledgments, a pop-up window will be displayed with a form to leave a comment. You can also enter an additional email address so that a copy of the Acknowledgment is sent, and, in the case of the claim acknowledgment, a list with the rejection types.

This event will be shown within the document preview in the notes section, and the XML of the event sent to the Tax Authority will be displayed:

and in the attachments section, as shown below:

i. Acknowledgment of Receipt or Receipt of Goods Event

When selecting Acknowledgment of Receipt or Receipt of Goods, the following pop-up window is displayed:

a. Acknowledgment type: the information of the previously selected acknowledgment type will be displayed.

b. Venue: enter the venue through which the goods receipt acknowledgment will be issued. For the acknowledgment of receipt, it will be necessary to enter a description of the acknowledgment in this field.

c. Approval status: shows the type of approval that will appear on the acknowledgment of receipt.

d. Send copy to: Enter the email address to which the notification that you generated the acknowledgment of receipt will be sent.

e. When finished, click Send.

ii. Accepted - Accepted (Discrepancies) - Rejected Event

2.*Accepted: Produces an acceptance acknowledgment.

3.*Accepted (Discrepancies): Generates an acknowledgment of receipt of the document's acceptance with some adjustments to be made.

4.*Rejected: Issues a rejection acknowledgment of the document.

Once you have selected one of these options, the following form will be displayed.

1.*Acknowledgment type: the information of the previously selected acknowledgment type will be displayed.

2.*Description: enter a statement explaining the selection of the acknowledgment type.

3.*Approval status:  shows the type of approval that will appear on the commercial acknowledgment. In the case of Rejection (Claim), the approval status will show a list from which we can choose the reason for the rejection.

4.*Send copy to: Enter the email address to which the notification that you generated the acknowledgment of receipt will be sent.

**5.**When finished, click Send.

This event will be reflected in the document preview in the notes section, and the XML of the event sent to the Tax Authority will be shown in the attachments section, as shown below:

Likewise, the Notification - Receipt Event will be shown in the document's status icons.

---

4.2.2. Apply commercial acknowledgments from the document preview

These events can also be generated from the Inbox document preview, which we will explore below.

This action can also be performed from the document preview using the Commercial acknowledgment button.

4.2.3. Icons according to the commercial acknowledgment

According to the previously assigned commercial acknowledgment, the document may show one of the following icons when viewed from Received:

1. Acknowledgment of receipt of the document: This status reports on the issuance of the acknowledgment for a document, which can be shown in two scenarios:

a.   Gray, which will be shown when the document does not yet have a commercial acknowledgment.

b.   Green, which indicates that the acknowledgment was issued successfully.

2. Goods or Service Receipt Event: This status shows the Receipt of Goods or Merchandise Service event; if this event is not present, the icon will be gray.

3. Acceptance or claim of the document:  For express or tacit acceptance, an icon with a thumbs-up will be shown in green; if rejected, an icon with a thumbs-down will be shown in red; if this event is not present, the hand will be in gray.

warning

For more details on the execution of commercial acknowledgments from the API available in this section, see the Inbox and API Manual.

---

5. FUNCTIONALITY FOR CUSTOMERS IN CHILE WHO ONLY REQUIRE CONTRACTING RECEPTION

This feature is designed for companies in Chile that need to contract only the document reception service with Gosocket, while keeping issuance with a different technology provider.

This option allows configuring an email address (or mailbox) of the issuer to which commercial events will be automatically forwarded.

The feature is configured as follows:

• Configuration in the SII: The customer must configure the Gosocket exchange mailbox directly in the Internal Revenue Service (SII) platform.
• Configuration in the Gosocket Platform: Within the Configuration section, go to the Policies tab and do the following:

1. Go to the Inbox  user  profile option.
2. Select the Configuration option
3. Enable the check "Enable only for Reception".
4. Enter the Forwarding Email: The email address to which events arriving at the exchange mailbox must be forwarded must be registered. This email must correspond to the customer's issuance provider mailbox, thus allowing that provider to receive and process the events related to the issued documents.
5. Click the  ***Save.***button

6. QUERY OF RECEIVED DOCUMENTS FROM GOSOCKET

Once the documents have been processed by the reception service, they can be viewed from the Gosocket portal in the Inbox/Received section. **

This section shows the following screen:

**1.**Filters section to optimize the search results. **

**2.**Display order control, with which you can modify the way search results are presented. **

**3.**List of options related to the export, commercial responses, and internal movements of Electronic Documents. **

**4.**Display section with the detail of the search result and representative icons of the most relevant status changes. **

warning

* For more information on these points, see the Inbox documentation.**

Once the document search is performed, the main grid will display the list of received documents that met the established search criteria; in this grid, in addition to relevant document information, the document's status can also be observed.

**1.**Tax authority validation.

**2.**Distribution validation.

**3.**Smart Supply status validation.

**4.**Acknowledgment of receipt.

**5.**Acknowledgment of receipt of the good or service.

**6.**Acknowledgment of Acceptance or claim of the document.

In the status column (1), the result of the applied validations will be shown, as explained in the section XML reception process.

Icon	Status	Validation
	VALIDATED	Document approved by the TA
	REJECTED*	Document rejected by the TA
	Not Available in ET	Document does not exist in the TA
❗	ERROR*	Document Rejected or internal exception by Gosocket
	CANCELLED	Document voided in the TA
	Signature Error	Document with signature error
	Schema Error	Document with schema error
	Schema error but the flow continues *	The XML has a schema error, but if the configuration is enabled, this option allows the reception flow to continue.

* Note: By clicking on the document, the document preview will open, where you can review the notes related to the reason for rejection.

* Note: for the case where the document remains in “ERROR” status, the user can reprocess it through the actions, in order to perform the schema, signature, or TA validations again. This process is explained in detail in the section Reprocessing.

* Note: Special configuration: The XML has a schema error, but if the configuration is enabled, this option allows the reception flow to continue:

This feature can be enabled independently for each company. Its purpose is that, if a schema error is detected in the XML when the document is received in Gosocket, the specific error detail will be automatically recorded in the document's "Notes" section.

Despite this finding, the document will continue with its normal flow toward the following reception validations, such as the signature and tax authority verification.

The document will remain in Inbox as follows:

In Gosocket, the document will remain in Validated ET with schema error status and the orange icon will be shown, as follows:

For more details on how to configure this feature, see the following section: XML Configuration Presents Schema Errors and Reception Flow Continues

---