xPOS Global Architecture

🏗️ General Architecture

The xPOS Core component functions as a multi-platform agent responsible for the transformation, validation, signature, and auditing of electronic documents before their sending to the tax authority or the Gosocket cloud.

---

Integration Flows by Country

xPOS operates with three integration models according to how each tax authority receives and responds to the electronic document state. The internal process of xPOS Core (XSD/Schematron validation, folio assignment, and signature) is common to all three; what changes is who dialogues with the tax entity and when the official state is known.

Model	Countries	Who sends to tax authority	When the official state is known
Synchronous	Colombia, Guatemala, Panama	xPOS Core	In the same call
Mixed (synchronous + asynchronous)	Costa Rica, Dominican Republic, El Salvador, Chile, Paraguay	xPOS Core	In a subsequent query
Asynchronous	Chile, Paraguay	Gosocket Cloud	Managed by the Gosocket cloud

note

Chile and Paraguay appear in two models because the client can choose whether the sending to the tax authority is done directly by xPOS Core (mixed model) or if it delegates it to the Gosocket cloud (asynchronous model).

Synchronous Flow — Colombia, Guatemala, and Panama

xPOS Core dialogues directly with the tax authority and obtains the definitive state within the same call. The response to the POS already contains the official result.

1. POS Client → xPOS Core: sends the document (JSON / XML / TXT).
2. xPOS Core: executes XSD/Schematron validation, folio assignment, and signature.
3. xPOS Core → Tax Authority: synchronous sending. xPOS Core waits for the official response.
4. Tax Authority → xPOS Core: acknowledge with the state approved or rejected. xPOS Core updates the DTE and synchronizes the Inbox (Emitidos).
5. xPOS Core → POS Client: response of process with the definitive state.

Mixed Flow (synchronous + asynchronous) — Costa Rica, Dominican Republic, El Salvador, Chile, Paraguay

The tax authority requires direct sending from the issuer, but the official state is delivered in a deferred manner. xPOS Core performs two trips against the tax authority: the first delivers the document, and the second queries the state.

1. POS Client → xPOS Core: sends the document (JSON / XML / TXT).
2. xPOS Core: executes XSD/Schematron validation, folio assignment, and signature.
3. First sending (asynchronous). xPOS Core delivers the document to the tax authority and receives an acknowledge of reception. The DTE is registered in the Inbox without state (synchronized).
4. xPOS Core → POS Client: response of process confirming that the document was accepted for processing.
5. Subsequent query. xPOS Core queries the DTE state to the tax authority.
6. Tax Authority → xPOS Core: acknowledge with the state approved or rejected. xPOS Core updates the DTE in the Inbox (Emitidos) and notifies the POS of the final state synchronization.

Why this model

It allows the POS not to be blocked waiting for official validation: it receives the reception notice immediately, and the synchronization of the definitive state arrives when the tax authority issues it.

Asynchronous Flow — Chile and Paraguay

xPOS Core does not dialogue with the tax authority: delivers the document to the Gosocket API and is the cloud who communicates with the SII (Chile) or the SIFEN (Paraguay).

1. POS Client → xPOS Core: sends the document (JSON / XML / TXT).
2. xPOS Core: executes XSD/Schematron validation, folio assignment, and signature.
3. xPOS Core → Gosocket API: asynchronous sending. Receives acknowledge from the cloud.
4. xPOS Core: synchronizes the Inbox (Emitidos) and returns to the POS the response of process.
5. Gosocket API → Tax Authority: the cloud sends the document asynchronously and processes the acknowledge corresponding.

Why this model

xPOS Core disentangles itself from communication with the tax authority: once the document is delivered to the cloud, the responsibility of sending, retries, and official state reconciliation remains in Gosocket.