Setup and Audit

Setup and Audit

Getting Mexico Localization Ready for Live Operations

Before any CFDI can be generated, iVendNext needs to know how to reach FacturaAPI — the SAT-authorised PAC that handles all CFDI stamping. This is handled through a single configuration record in iVendNext Desk called E Invoice Setting. Once configured and tested, CFDI generation runs automatically for every POS transaction with no further setup required at store level.


This article covers how E Invoice Setting works, how to verify connectivity before going live, how iVendNext logs every FacturaAPI interaction for audit, and how background processing keeps POS performance unaffected by CFDI generation.


The E Invoice Setting Record

All integration parameters for Mexico Localization are stored in a single E Invoice Setting record in iVendNext Desk. This record contains:


  • FacturaAPI Server URL — the endpoint that iVendNext sends CFDI requests to

  • Secret Key — the API credential that authenticates iVendNext with FacturaAPI

  • Enable E Invoice toggle — activates or deactivates CFDI generation globally

  • Enable Cancellation toggle — activates or deactivates CFDI cancellation through FacturaAPI


Having all integration parameters in one record simplifies administration. An IT administrator can enable or disable CFDI generation system-wide by toggling a single field, without touching POS Profiles or any transaction-level configuration. The same record also controls whether cancellation requests are permitted — useful in scenarios where cancellation policy needs to be restricted centrally.



Encrypted API Key Storage

The FacturaAPI Secret Key is a sensitive credential. Exposing it — in a log file, an API response, or a system administration screen — would allow unauthorized parties to generate or cancel CFDIs on behalf of the business.


iVendNext stores the Secret Key using a Password fieldtype, which applies encryption at the database level. The key is never displayed in plain text after it is saved, and it does not appear in any Integration Request log, error message, or API response visible to system users. This protects the credential from accidental exposure during routine administration or system troubleshooting.


Server Ping and Connectivity Testing

Before activating CFDI generation for live trading, IT administrators need confidence that iVendNext can successfully reach FacturaAPI with the credentials provided. The Ping Server button in E Invoice Setting sends a test request to FacturaAPI and confirms whether the connection is live and the credentials are valid.


This test is particularly valuable during initial setup, after a credential rotation, or when troubleshooting a connectivity issue after a network change. Rather than waiting for a real POS transaction to fail before discovering a configuration problem, the Ping Server button provides an immediate, low-risk connectivity check that can be run at any time from iVendNext Desk.


Integration Request Logging

Every call that iVendNext makes to FacturaAPI — whether for CFDI generation, cancellation, or a connectivity test — creates an Integration Request record in iVendNext Desk. Each record stores:


  • The full request payload sent to FacturaAPI

  • The full response received from FacturaAPI

  • The timestamp of the call

  • The status of the request (success or failure)



Info
This log is the primary audit trail for all CFDI activity in iVendNext. Finance teams can use it to verify that a specific invoice was stamped, retrieve the FacturaAPI response for a given transaction, or investigate why a particular CFDI generation attempt failed. Every call is traceable back to a specific POS Invoice, and every response — including SAT UUIDs and error codes — is preserved in full.


For organisations subject to SAT audit or internal compliance review, the Integration Request log provides a complete, tamper-evident record of every fiscal interaction with FacturaAPI.


Error Log for Failed Calls

When a CFDI generation or cancellation call fails — due to a network error, an invalid payload, a FacturaAPI rejection, or a SAT-side issue — iVendNext records the failure in two places: the Integration Request record for that call, and the system Error Log.


Notes

The Integration Request log is the primary operational record for finance and operations staff. The Error Log is the technical record for IT administrators. A failure in both logs gives each team the information they need without crossing into the other's toolset.


The error entry in the Error Log includes the exception detail and a traceback, enabling IT teams to identify whether the failure was a misconfiguration, a payload issue, or an external service problem — and resolve it without reproducing the transaction.



Background Job Processing

Generating a CFDI involves an outbound API call, a FacturaAPI response, and SAT validation — a process that can take several seconds. If CFDI generation ran synchronously, cashiers would experience noticeable delays at checkout.


NotesiVendNext prevents this by running all FacturaAPI calls as background jobs via the Redis queue. When a POS Invoice is submitted, the CFDI request is queued and processed asynchronously. The POS interface is released immediately and the cashier moves to the next customer while the stamp is obtained in the background and the UUID written back to the invoice.

This architecture also means bulk CFDI re-generation does not impact the live POS environment. Re-generation jobs are queued in the same background layer, so finance teams can recover a large batch of missed stamps without any effect on concurrent POS activity.


Sandbox and Production Mode

During implementation and testing, it is essential that test CFDI documents do not enter SAT's production records. iVendNext supports this by allowing the FacturaAPI Server URL in E Invoice Setting to point to FacturaAPI's sandbox environment rather than its production endpoint.



Info
In sandbox mode, CFDI documents are generated and stamped within FacturaAPI's test environment. They have no fiscal validity and do not appear in SAT's live records. This allows implementation teams to test the full CFDI workflow — including generation, cancellation, and bulk re-generation — without creating real fiscal documents.


Switching to production requires only a URL change in E Invoice Setting. All other configurations remains identical between environments, making the cutover straightforward and low-risk.


What the Audit Trail Covers

Across the Integration Request log, the Error Log, and data on individual POS Invoice records, iVendNext provides a complete audit trail for every CFDI-related event:


  • Every CFDI generated, including SAT UUID, certificate number, SAT signature, and stamp timestamp

  • Every cancellation, including the SAT motive code and the FacturaAPI response

  • Every failed generation or cancellation attempt, including the error detail and call payload

  • Every payment complement generated for deferred sales



Notes
This coverage means that at any point — whether for an internal review, a customer dispute, or a SAT audit — finance and IT teams can reconstruct the complete fiscal history of any POS Invoice without relying on external portals or FacturaAPI's own records.



    • Related Articles

    • Audit and Context

      Overview Two features of iVendNext Copilot — the full audit trail and live context injection — operate quietly in the background of every conversation. Neither is visible as a button or setting in the chat interface, but both matter significantly for ...

    • eTIMS Setup in Kenya

      What Is eTIMS and Why It Matters Kenya Revenue Authority (KRA) operates the Electronic Tax Invoice Management System — eTIMS — as the country's mandatory tax compliance platform for all VAT-registered businesses. Every sale, purchase, and stock ...

    • Sales Person Setup

      Why Sales Person Configuration Matters Getting the Sales Person setup right before the feature goes live at the till determines how smoothly assignment works for cashiers and how useful the resulting commission data is for management. A thoughtfully ...

    • Understanding POS Input Forms: Key Components and Setup

      Overview A Point of Sale (POS) Input Form captures transaction details, customer information, and payment methods. This guide explains its key components and provides a step-by-step setup process for first-time users. 1. Key Components of a POS Input ...

    • Setup and Reporting

      The iVendNext Kenya M-Pesa Integration is configured through a single settings record per Safaricom shortcode. Creating that record wires up all the payment infrastructure needed — the payment gateway, mode of payment, and API connection — in one ...