Mexico: Reception of documents (MS)

1. XML RECEPTION PROCESS

This process allows different types of documents to be received from customers and suppliers through the channels offered by Gosocket. Once received, both the issuer and the recipient can 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:

Mexico reception process

1. XML document submission methods in Gosocket:

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

a. The supplier performs the manual upload of the XML file through the Upload option in Gosocket. The requirements and conditions for this process are detailed in the section Manual upload.

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

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

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, signature, and the corresponding validation with the Tax Authority (TA) validations.

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 tax format, the document reception flow will be stopped due to the schema error, it will be registered in Gosocket with the status Schema Error and the interface will display the icon and the reason for rejection will be detailed in the document notes, as follows:

Schema error icon in inbox

Document detail Notes section - Schema Error

Detail of 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 this 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 "Notes" section of the document.

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

The document will remain in Inbox as follows:

• In Gosocket the document will remain in status Validated ET with schema error and the icon will be shown in orange, 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

Second, an electronic signature validation of the document is performed to ensure that the information has not been altered. This validation can result in one of the following outcomes:

f. Failed: This means the document has been altered, the document reception flow will be stopped due to the signature error, and it will therefore be registered in Gosocket with the status Signature Error, the interface will display an icon and the preview notes will indicate the reason for the rejection, as follows:

Signature error icon in Inbox

Document detail Notes section - Signature Error

Detail of XML processing for the signature error

g. Successful: If the XML electronic signature validation is correct, the document will continue with the reception flow.

Document detail Notes section - Successful signature validation

5.Document validation with the Tax Authority

Third, the query validation with the Tax Authority is performed. This validation can produce several outcomes:

h. Document has an internal exception by Gosocket ❗

When performing the validation query with the Tax Authority for the document and Gosocket cannot connect with the TA service or there are communication errors with the service, the document status changes to ERROR and it will be assigned the icon ❗.

Error icon in inbox: No communication with the TA.

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

i. Automatic retries when the document has the status not available in the TA .

At this stage of the process, when the document does not exist in the Tax Authority, this indicates 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 in status Not Available in ET and will be assigned the corresponding icon .

• An automatic retry 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 status Not Available in ET and retain the corresponding icon .

• The current retry parameter is 30 attempts in 1 hour (the query is retried 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 are 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 the other line will show another message: “The maximum number of retries for the status query with the TA was reached”, as follows:

and after these retries two responses can result:

j. If after 30 attempts the document is still not found, it will remain permanently in status Not Available in ET, showing the following icon in the Inbox.

Rejected icon in inbox: Document validation with the TA

k. If during these retries the document is found in the TA, the process continues and two responses can result:

• If the document exists, but it has a Cancelled status (For more details, see literal L)
• If the document exists, but it has an Active status (For more details, see literal m)

L. When the document has the Cancelled status with the TA

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

m. When the document has the Active status with the TA, the process continues and two responses can result:

n. If the document issuer is NOT on the EFOS list

If the result of the previous validations (Schema and Signature) is satisfactory and the query with the tax authority is successful:

• It is registered with the SAT
• Its status at that time is “Active”
• The issuer is not on the EFOS list.

If the document meets the above validations, it will be registered in Gosocket with the status Accepted. In the interface, this status will be identified with a green check icon.

Accepted icon in inbox: If the document issuer is NOT on the EFOS list

Document detail Notes section - Successful document validation with the SAT

o. If the document issuer is on the EFOS list

If the document issuer is on the EFOS list or there is any other reason for rejection with the Tax Authority, the document will be marked in inbox with the red exclamation symbol  and in the received documents query screen (Inbox) it will remain with status Rejected and the notes will indicate the reason for the rejection.

Rejected icon in inbox: If the document issuer is on the EFOS list

Document detail Notes section - Document validation with the SAT rejected

6. Inbox iconography for the reception validation results

Finally, both the issuer and the recipient can view the results of the XML document validations in Inbox, as follows:

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

2. MANUAL DOCUMENT REPROCESSING

Additionally, in Inbox a button was implemented that allows manually reprocessing tax documents that have the status “ERROR” ❗, “Not Available in ET” , “Signature error” and “Schema error” .

info

Note: This option only allows reprocessing documents that were sent through the exchange mailbox, the reception API, or the 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 without validating signature.
• Inbox/Received/Options/Actions/Reprocess document.

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

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 reprocessing types generated through this option, the notes section will indicate:

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

This button allows performing a reprocessing of 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 into account the schema validation; however, when selecting the document and applying this reprocessing without validating schema, 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.2. Reprocess document without validating signature:

Allows the document to go through the reception validations without taking into account the signature validation; however, when selecting the document and applying this reprocessing without validating signature, the system:

• Records the email of the user who performed the document reprocessing.
• Generates a note “Document processed without signature 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 selecting the document and applying this reprocessing, the system:

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

---

3. XML SUBMISSION METHODS

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

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

3.1. Manual upload of the XML through Upload in Gosocket

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 has been received, the solution automatically starts the processing and validation flow.

Once the XML file is received through the manual upload option, it will identify:

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

b. When clicking the “Details” button, a popup will be displayed with the “Error Details” identifying the possible errors that the XML file uploaded manually through this option may contain, and if the document has no errors instead, 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 performed.

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 an XML format.

The tax documents that can be received are:

• Income CFDi
• Expense CFDi
• Transfer CFDi
• Payroll CFDi
• Payments CFDi

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

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

• Sandbox (Testing): mx_ms_sbx@inbound.gosocket.com
• Production: mx@recepcionprd.gosocket.net

info

Note: If a custom exchange mailbox is needed for a client, 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, since this will prevent them from being rejected by the application.

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

• Income CFDi
• Expense CFDi
• Transfer CFDi
• Payroll CFDi
• Payments CFDi

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

c. They can be sent individually or several XMLs in the same email.

d. Several XMLs can be sent compressed in a file and only the .zip extension will be 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 others as required.

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

h. The solution has the ability to process the graphic representation PDFs, in case they are included, and attached documents that arrive at the mailbox, where once received they are stored and associated with their respective 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: Factura12345.xml and Factura12345.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 attached file of any extension, they are associated as attached documents.

warning

Note: If there are PDF files with a different name than 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 storage of the graphic representation will only be performed 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 sending the XML; 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 API's

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 more 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 stores it securely on the platform.

a. Tracking management (Tracking)

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 Gosocket the XML and the 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 respective 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 correctly stored in Inbox, the following actions will be available:

• Reception validations (Automatic): Technical verification of compliance with standards, 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 body after the fiscal validation.

• Receiver message (Automatic): Application of receiver message events according to the tax authority's current regulations.
• Smart Supply validations (Configuration on demand): Application of logical rules and approval flows configured in the Smart Supply module.
• File distribution (Configuration on demand): Once the document has been processed on the Gosocket platform, and based on the prior parameterization of the distribution rules, the system executes 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 email submission.

warning

You can find the configuration details of the Reception API in 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 stores it securely 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 Gosocket's Inbox module through the  endpoint: POST - SendDocumentToUpload
• Persistence: Ensures the storage of the XML file on the platform's servers for its subsequent management.

b. Tracking management (Tracking)

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

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

c. Post-storage processing actions

Once the document has been correctly stored in Inbox, the following actions will be available:

• Reception validations (Automatic): Technical verification of compliance with standards, 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 body after the fiscal validation.

• Receiver message (Automatic): Application of receiver message events according to the tax authority's current regulations.
• Smart Supply validations (Configuration on demand): Application of logical rules and approval flows configured in the Smart Supply module.
• File distribution (Configuration on demand): Once the document has been processed on the Gosocket platform, and based on the prior parameterization of the distribution rules, the system executes 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 email submission.

warning

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

---

4. QUERY OF DOCUMENTS RECEIVED FROM GOSOCKET

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

This section shows the following screen:

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

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

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

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

warning

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

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

**1.**Tax Authority validation.

**2.**Distribution validation.

**3.**Smart Supply status validation.

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 with Cancelled status with the SAT
	Signature Error	Document with signature error
	Schema Error	Document with schema error
	Schema error but flow continues *	The XML has a schema error, but if this configuration is enabled, this option allows the reception flow to continue.

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

* Note: for the case where the document remains in status “ERROR”, 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 this 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 "Notes" section of the document.

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

The document will remain in Inbox as follows:

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

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