Vessi.cl Electronic Invoicing

This plugin allows you to automatically generate and send electronic invoices and receipts using the Vessi.cl API from WooCommerce. Customers can choose the type of document (invoice or receipt) during the checkout process.

Key Features:

• Integration with Vessi.cl API
• Automatic issuance upon payment completion
• Custom data capture at checkout
• Support for Chilean electronic invoices and receipts
• Easy configuration from the admin panel

External Services

This plugin integrates with an external service to generate and send Chilean Electronic Tax Documents (DTE).

Service Name: Vessi.cl – Electronic Invoicing API
Service Type: Private REST API endpoint for the generation and submission of electronic tax documents to the Chilean Internal Revenue Service (SII).

Data Sent:
Depending on the selected document type (invoice or receipt), the following information is sent to the Vessi.cl API:
– Emitter data (provided in the plugin settings).
– Customer data:
– RUT
– Legal name / full name
– Business activity (giro)
– Address
– Municipality (comuna)
– Region
– Email address
– Order details:
– Product names, quantities, and prices
– Net amounts, VAT, and totals
– WooCommerce order reference data (order ID, date).

When Data Is Sent:
– Automatically when a WooCommerce order is marked as paid (woocommerce_payment_complete), if the “Auto-issue document” option is enabled in the plugin settings.
– Manually, when the admin triggers the issuance from the plugin’s interface.

Local log: the last 50 requests and responses are kept in the site’s own database (table {prefix}vfec_vessicl_api_log) so the shop can diagnose failed documents. They include the customer data listed above, never the API credentials, and are deleted when the plugin is deleted.

Purpose of Data Transfer:
– To generate a valid Electronic Tax Document (DTE) and register it with the Chilean Internal Revenue Service (SII) in compliance with local tax regulations.

Service Terms and Privacy Policy:
– Vessi.cl Terms and Conditions: https://vessi.cl/terminos
– Vessi.cl Privacy Policy: https://vessi.cl/privacidad
(If you operate an intermediate endpoint between your plugin and Vessi.cl, you must publish and link to your own Terms and Privacy Policy on your domain.)

1. Upload the plugin to the /wp-content/plugins/ directory.
2. Activate the plugin through the “Plugins” menu in WordPress.
3. Go to Invoicing > Settings and complete the required fields.
4. Make sure WooCommerce is installed and active.

Do I need a Vessi.cl account?

Yes, you need an active account with valid credentials (Access Key, Secret Key, and emitter RUT).

Does this plugin work outside Chile?

No, it is designed specifically for Chilean electronic invoicing using Vessi.cl.

Where can I configure the invoicing data?

In the WordPress admin menu: Invoicing > Settings.

1.0.11

• Added: the invoice or receipt is now emailed to the customer as soon as it is issued, whether automatically on payment or with “Generar”. Until now nothing was sent when a document was issued, even though the automatic-issuing option said it would: the only way to send it was the “Enviar” button, order by order. It goes to the “Email para DTE” given at checkout for an invoice, or to the billing email. The result is added as an order note and shown after “Generar”. A new setting, “Enviar al cliente” (on by default), turns it off; “Enviar” still works for resending.
• Fixed: the email said the PDF was attached, but it only carried a link. The PDF is now attached, and the link is kept.
• Fixed: with no “Email Remitente” in the settings, every email failed. It now falls back to the sender of WooCommerce’s emails.
• Fixed: the sender name was always “Tienda WooCommerce”. It is now the sender name of WooCommerce’s emails, or the site name.
• Fixed: after sending, the plugin removed every other plugin’s sender filters for the rest of the request, which could break SMTP plugins. It now removes only its own.
• Changed: the “Enviar” button suggests the email the document is sent to (for receipts it suggested the invoice email field, usually empty).
• Added: help tips next to every setting on the settings page — what each field is for, where to get it and what happens with each option. They open on hover, with the keyboard or by tapping them.
• Fixed: the settings page did not fit on a phone screen (the API URL field had a fixed 700 px width).

1.0.10

• Fixed: on a shop with taxes enabled but no tax rate that applies to the order — none configured, or one limited to another country or region — invoices were issued 19% above what the customer paid, because the full price was sent as the net amount and the API adds VAT on top of it. Receipts were not affected.
• Fixed: a tax ID (RUT) typed without the dash, or with dots — “123456785”, “12.345.678-5” — passed validation but was sent to the API as typed, and the API rejected it, so the invoice was not issued. The RUT is now always stored and sent as 12345678-5, including on orders saved before this version. The issuer RUT in the settings is accepted in any format and its check digit is now validated too.
• Fixed: invoice totals could be a few pesos above or below what the customer paid when a quantity was greater than one, because the net unit price was rounded to whole pesos (2 × $10.000 came out at $19.999). Net unit prices are now sent with four decimals and chosen so the invoice total matches the amount paid; for the few totals that no net amount can produce exactly, the difference is one peso.
• Fixed: receipt totals could be one peso off what the customer paid when the price with VAT did not divide evenly by the quantity (for example, prices entered without tax). Unit prices on receipts are now sent with four decimals and the receipt total matches the amount paid.
• Changed: the net amount of each line is now based on the VAT recorded on the order, not on the shop’s current tax setting, so a document issued manually after the tax settings change still matches what was charged.
• Added: the settings page checks the WooCommerce setup and warns when it can make a document differ from what was charged — a store currency other than CLP, prices with decimals, taxes enabled with no rate for all of Chile, a rate other than 19%, products in a tax class with no 19% rate for Chile, or products with “Tax status: None”.

1.0.9

• Added: an API log under Invoicing > API Log with the last 50 calls to the Vessi API — what was sent and what came back, with the order, document type, HTTP status and duration. The PDF in the response is not stored. Only users who manage WooCommerce can see it, and it can be cleared at any time.
• Added: when the API does not issue a document, the order now gets a note with the reason the API gave (for example “No quedan folios disponibles”), and the admin message shows it too. Until now an automatic issuance that failed left no trace at all, and a manual one only said “Error al generar boleta”.
• Fixed: the “Issue automatically” setting never showed as ticked, even when it was on. Because an unticked box is not submitted, the next save of the settings page — for example, when updating the API credentials — silently turned automatic issuing off. Present since the first release.
• Fixed: a receipt ignored the name and address the customer entered at checkout and always printed “Cliente Final” and “Sin Dirección”. It now uses the invoice details if they were given, then the billing details, then the shipping details.
• Fixed: saving the settings with an invalid issuer tax ID stored some fields and not others, and left the page blank. All fields are now validated first; if anything is invalid, nothing is saved and the form is shown again with the error.
• Fixed: an invalid API URL was rejected and then saved anyway. It is now normalised, validated, and only saved if it is a valid URL.

1.0.8

• Fixed: a customer who chose Invoice could end up with a receipt instead, without being told. The choice was only recorded once they interacted with the invoice fields, and any order whose invoice details had not reached the session was silently rewritten as a receipt with those fields deleted. The choice is now recorded as soon as it is made, and an order that asks for an invoice stays an invoice.
• Added: the invoice details are now validated on the server, on both the block and the classic checkout. Until now the only check was a browser alert that did not stop anything, so an order could be placed asking for an invoice with no tax ID at all. Incomplete details now block the order with a message naming the missing fields.
• Added: when details still arrive incomplete, a note on the order tells the shop exactly what is missing and where to complete it.
• Fixed: the plugin’s own scripts and styles were served with fixed version numbers that never changed, so a returning visitor’s browser kept using its cached copy after an update. They now carry the plugin version.
• Fixed: a receipt no longer forwards an invalid tax ID. It falls back to the generic consumer tax ID and says so on the order.
• Fixed: issuing an invoice twice is now refused, as it already was for receipts.
• Fixed: with an empty tax ID the checkout said the tax ID was invalid instead of asking for the missing fields.
• Removed: dead code — a branch that never ran because it tested for the wrong order status, and a user meta value nothing ever read.
• Fixed: settings values are no longer escaped twice, which could corrupt a stored value containing certain characters.

1.0.7

• Added: the invoicing details — tax ID (RUT), legal name, business activity, address, email, municipality and region — and the document type can now be edited from the order screen, while no document has been issued. Until now they could only be captured at checkout, so an order that arrived without them could never be invoiced at all: the note left by a failed issuance asked the shop to collect the data from the customer, with nowhere to enter it.
• Added: a tax ID entered in the admin is validated with the same check-digit test used at issuance. An invalid one is not saved and the reason is shown.
• Once a document has been issued the details become read-only. Changing them afterwards would not change the document already registered with the tax authority.

1.0.6

• Fixed: the plugin did nothing at all on the classic (shortcode) checkout. The document type selector was never inserted, so customers could not request an invoice, and neither the document type nor the invoice details were ever saved to the order — leaving it impossible to issue. The selector now has a server-side anchor on the classic checkout, and the order data is saved there through the same code path used by the block checkout.
• Fixed: when the selector had nowhere to be inserted, the script retried on every animation frame forever — around 60 times a second, for as long as the checkout page stayed open. The retry is now bounded.

1.0.5

• Fixed: an invoice for an order with no valid receptor tax ID (RUT) was issued to a generic one, producing a tax document of no use to the recipient. Nothing is issued now; instead a private note is added to the order so the shop can contact the customer, collect the data and issue it afterwards. The RUT check digit is validated on the server, not only in the browser.
• Fixed: shipping costs and fees were left out of the document, so any order with a delivery charge was invoiced for less than the customer paid.
• Security: API credentials are no longer passed as function arguments. PHP records call arguments in stack traces, so any fatal error in the signing path wrote them (truncated) to the site’s error log. They are now read inside the signing function.
• Added: HPOS compatibility is now declared, and order metadata is written only through the WooCommerce order API. WooCommerce blocks High-Performance Order Storage while an undeclared plugin is active, and the legacy post-meta writes created a second, divergent copy of the data.
• Removed: a leftover emular_webpay debug hook that force-completed payment on an order from a URL parameter.
• Added: orders with no document type recorded — created manually, imported, or placed before the plugin was installed — can now be issued a receipt. Previously the sales list showed no button at all and there was no way to issue them.

1.0.4

• Fixed: every document was issued for more than the customer paid. Line prices were multiplied by 1.19 regardless of the store’s tax configuration and of the document type. On a receipt the total came out 19% high; on an invoice 41.6% high, because for that document type the API adds VAT on top of the price it receives. Prices now come from what the customer actually paid, after discounts, converted per document type and rounded to whole pesos.
• Fixed: invoices were always issued to RUT 11111111-1. The customer’s RUT captured at checkout is now used.
• Fixed: issuing an invoice also overwrote the receipt metadata (folio, PDF URL, base64) with the invoice’s values, which corrupted the sales list and the “already issued” check.
• Fixed: a line item with quantity 0 caused a division by zero.

1.0.3

• Fixed: no document could be issued at all. The file that builds the API request was stored in a non-UTF-8 encoding, so json_encode() returned false and an invalid request body was sent. The result was a PHP fatal error and a misleading browser message (“JSON.parse: unexpected character” or “Unexpected end of JSON input”). Every installation was affected; this is the reason to upgrade.
• Fixed: the plugin header reported 1.0.0 regardless of the version actually released, so WordPress showed the wrong version and update checks were unreliable.
• Removed: a stale, unused duplicate of assets/js/checkout.js that shipped inside the package. It was never loaded, but it misled anyone editing the plugin.

1.0.0

• Initial release with full integration to Vessi.cl