Changelog
This page lists the latest releases of the JoFotara WooCommerce Pro plugin and the key changes in each. Customers with an active support plan can download the newest version from their account or straight from the WordPress dashboard.
v2.2.1
Security 2026-08-16
### Fixed
- **Credit notes were rejected with `[CORE-400-003] invoice: The unit price must match the
unit price in the original invoice.`** A credit note recalculated its figures from the
live order instead of reusing the ones that were actually filed, so any difference
between the two calculations was refused by JoFotara. The worst case: when a refunded
line could not be mapped back to its order item, the unit price was re-derived from
WooCommerce's 2-decimal refund total — a 30.00 → 25.00 coupon line filed at
`10.000000000` was credited at `8.333333333`. Credit notes now **replay the exact lines
that were submitted**; for a partial refund only the quantity changes, never the price.
- **Invoice amounts no longer drift from the order.** The unit price was sent as an
unrounded quotient of the line subtotal and the quantity, so a 10.00 line over 3 units
was filed as `3.333333333` × 3 = `9.999999999` rather than the 10.00 WooCommerce shows.
Unit prices are now placed on the 9-decimal grid the invoice is serialised with, and the
rounding residual is folded into that line's discount, so every line — and the invoice
total — matches the order exactly.
- **Credit-note discounts no longer drift.** A line discount filed as `5.000000000` was
re-derived on the credit note as `round(5 / 3, 9) × 3` = `5.000000001`.
- Partial-refund credit notes could fail before submission with *"Tax total amount would
make tax inclusive amount invalid"*. The bundled SDK checked
`(exclusive − discount + tax)` against a total it had computed as
`(exclusive + tax − discount)`; those are mathematically equal but can differ by one unit
in the last place in binary floating point. `InvoiceTotals::setTaxTotalAmount()` now
applies the same `0.000000001` tolerance the SDK already used in `setPayableAmount()`.
- A refunded line that cannot be matched to the original invoice now fails with an explicit
error instead of inventing a unit price the tax authority would reject.
### Added
- The exact line items sent with an invoice — ID, quantity, unit price, discount, tax
category and rate — are recorded on the order in `_jofotara_invoice_data['lines']`, so a
later credit note can reproduce them byte for byte.
- **Recovery for invoices submitted by earlier versions**, which recorded no line data. A
credit note for one of those is built from, in order of preference:
1. the stored line items, when present;
2. the submitted invoice document JoFotara echoed back (`submittedInvoice`), parsed for
the exact `cbc:PriceAmount` values the tax authority holds;
3. a reconstruction using the *previous* release's arithmetic — deliberately not the new
one, which would produce a unit price that was never filed.
The credit note's reference amount likewise falls back to the `cbc:PayableAmount` recorded
in that document instead of the rounded WooCommerce order total.
### Changed
- Line items are built once as an explicit specification and applied to the SDK in a single
place, shared by invoices and credit notes, rather than assembled twice by two routines
that could disagree.
- **Credit notes were rejected with `[CORE-400-003] invoice: The unit price must match the
unit price in the original invoice.`** A credit note recalculated its figures from the
live order instead of reusing the ones that were actually filed, so any difference
between the two calculations was refused by JoFotara. The worst case: when a refunded
line could not be mapped back to its order item, the unit price was re-derived from
WooCommerce's 2-decimal refund total — a 30.00 → 25.00 coupon line filed at
`10.000000000` was credited at `8.333333333`. Credit notes now **replay the exact lines
that were submitted**; for a partial refund only the quantity changes, never the price.
- **Invoice amounts no longer drift from the order.** The unit price was sent as an
unrounded quotient of the line subtotal and the quantity, so a 10.00 line over 3 units
was filed as `3.333333333` × 3 = `9.999999999` rather than the 10.00 WooCommerce shows.
Unit prices are now placed on the 9-decimal grid the invoice is serialised with, and the
rounding residual is folded into that line's discount, so every line — and the invoice
total — matches the order exactly.
- **Credit-note discounts no longer drift.** A line discount filed as `5.000000000` was
re-derived on the credit note as `round(5 / 3, 9) × 3` = `5.000000001`.
- Partial-refund credit notes could fail before submission with *"Tax total amount would
make tax inclusive amount invalid"*. The bundled SDK checked
`(exclusive − discount + tax)` against a total it had computed as
`(exclusive + tax − discount)`; those are mathematically equal but can differ by one unit
in the last place in binary floating point. `InvoiceTotals::setTaxTotalAmount()` now
applies the same `0.000000001` tolerance the SDK already used in `setPayableAmount()`.
- A refunded line that cannot be matched to the original invoice now fails with an explicit
error instead of inventing a unit price the tax authority would reject.
### Added
- The exact line items sent with an invoice — ID, quantity, unit price, discount, tax
category and rate — are recorded on the order in `_jofotara_invoice_data['lines']`, so a
later credit note can reproduce them byte for byte.
- **Recovery for invoices submitted by earlier versions**, which recorded no line data. A
credit note for one of those is built from, in order of preference:
1. the stored line items, when present;
2. the submitted invoice document JoFotara echoed back (`submittedInvoice`), parsed for
the exact `cbc:PriceAmount` values the tax authority holds;
3. a reconstruction using the *previous* release's arithmetic — deliberately not the new
one, which would produce a unit price that was never filed.
The credit note's reference amount likewise falls back to the `cbc:PayableAmount` recorded
in that document instead of the rounded WooCommerce order total.
### Changed
- Line items are built once as an explicit specification and applied to the SDK in a single
place, shared by invoices and credit notes, rather than assembled twice by two routines
that could disagree.
v2.2.0
Security 2026-07-20
### Added
- **Remote block (vendor kill switch) is now enforced across the whole admin.** When a site is blocked from the vendor's dashboard, the plugin shows a full **"This plugin has been blocked"** page in place of the JoFotara settings tab and the license screen — even on a site with no license — and turns the plugin off: no invoices or credit notes are sent to JoFotara. The block state takes precedence over the license/activation UI, and the page links to the developer for support (customer portal + Telegram).
- **"How to get a license" guidance** on the activation screen, with a direct link to purchase a license, plus a "get a license" link in the unlicensed admin notice.
### Changed
- **The JoFotara settings tab now requires an active license.** All configuration fields are hidden — and saving is blocked — until the plugin is activated with a valid key; an unlicensed or revoked site sees a "license required" panel instead. A footer credits the developer and links to support (portal + Telegram).
- Plugin and Author header links now point to the vendor site and customer portal.
### Security
- The vendor-block check runs **before** the license check on every admin surface and in the invoice / credit-note pipeline, so a tampered or unlicensed copy cannot bypass a block by stripping out the license logic.
- **Remote block (vendor kill switch) is now enforced across the whole admin.** When a site is blocked from the vendor's dashboard, the plugin shows a full **"This plugin has been blocked"** page in place of the JoFotara settings tab and the license screen — even on a site with no license — and turns the plugin off: no invoices or credit notes are sent to JoFotara. The block state takes precedence over the license/activation UI, and the page links to the developer for support (customer portal + Telegram).
- **"How to get a license" guidance** on the activation screen, with a direct link to purchase a license, plus a "get a license" link in the unlicensed admin notice.
### Changed
- **The JoFotara settings tab now requires an active license.** All configuration fields are hidden — and saving is blocked — until the plugin is activated with a valid key; an unlicensed or revoked site sees a "license required" panel instead. A footer credits the developer and links to support (portal + Telegram).
- Plugin and Author header links now point to the vendor site and customer portal.
### Security
- The vendor-block check runs **before** the license check on every admin surface and in the invoice / credit-note pipeline, so a tampered or unlicensed copy cannot bypass a block by stripping out the license logic.
v2.1.0
Security 2026-07-09
### Changed
- **Invoices are now sent to JoFotara ONLY when an order becomes Completed.** The Processing trigger has been removed; Pending Payment, Processing, On Hold, Draft and custom statuses (e.g. "Refund Requested") never cause a submission. The rule is enforced inside the generator itself, so the manual order action and programmatic calls also respect it (filter: `jofotara_wc_invoice_trigger_statuses`).
- **Strictly one credit invoice per order.** Once a credit invoice has a JoFotara UUID, no further credit invoice is ever sent for that order (cancellation, refund or manual action) — a note is added to the order explaining the skip.
### Added
- **Hard duplicate protection for invoices**: an order that already has a JoFotara invoice UUID is never submitted again, from any code path; skipped attempts add an explanatory order note.
- **Atomic cross-process locks** around invoice and credit-invoice submission (via the options table's unique-key constraint, with stale-lock takeover), so simultaneous triggers — e.g. a payment-gateway webhook racing an admin action — cannot double-send a tax document.
### Fixed
- The manual "Generate JoFotara Invoice" action no longer bypasses the duplicate check, and no longer adds misleading duplicate/failed order notes (the generator itself now records the outcome exactly once).
- **Invoices are now sent to JoFotara ONLY when an order becomes Completed.** The Processing trigger has been removed; Pending Payment, Processing, On Hold, Draft and custom statuses (e.g. "Refund Requested") never cause a submission. The rule is enforced inside the generator itself, so the manual order action and programmatic calls also respect it (filter: `jofotara_wc_invoice_trigger_statuses`).
- **Strictly one credit invoice per order.** Once a credit invoice has a JoFotara UUID, no further credit invoice is ever sent for that order (cancellation, refund or manual action) — a note is added to the order explaining the skip.
### Added
- **Hard duplicate protection for invoices**: an order that already has a JoFotara invoice UUID is never submitted again, from any code path; skipped attempts add an explanatory order note.
- **Atomic cross-process locks** around invoice and credit-invoice submission (via the options table's unique-key constraint, with stale-lock takeover), so simultaneous triggers — e.g. a payment-gateway webhook racing an admin action — cannot double-send a tax document.
### Fixed
- The manual "Generate JoFotara Invoice" action no longer bypasses the duplicate check, and no longer adds misleading duplicate/failed order notes (the generator itself now records the outcome exactly once).
v1.1.0
2026-06-30
### Added
- **Credit invoices (credit notes)**: a JoFotara credit invoice (UBL type `381`) is now
issued automatically when an order is cancelled or refunded — the feature that was
previously documented but never wired up.
- `woocommerce_order_status_cancelled` → full credit note mirroring the original invoice.
- WooCommerce refunds (`woocommerce_order_refunded`) → a credit note for the refunded
items/amount (supports partial refunds).
- Manual status change to "Refunded" with no refund object → full credit note.
- New manual order action: **Issue JoFotara Credit Invoice (cancel)**.
- Duplicate prevention: only one *full* credit note per order; partial refunds may each
get their own credit note. Stored in `_jofotara_credit_invoices` (+ latest in
`_jofotara_credit_invoice_data`).
- New hooks: `jofotara_wc_credit_invoice_generated`, `jofotara_wc_credit_invoice_generation_failed`.
- **Official JoFotara QR on PDF invoices**: the QR returned by JoFotara on a successful
submission is now injected into invoices generated by the WebToffee plugin
*WooCommerce PDF Invoices, Packing Slips, Delivery Notes and Shipping Labels* (via the
`wt_pklist_alter_final_order_template_html` filter), shown **only** when the order was
actually submitted to JoFotara. The WP Overnight PDF plugin is also supported
(`wpo_wcpdf_after_order_details`).
- Filters to customize: `jofotara_wc_webtoffee_document_types`, `jofotara_wc_webtoffee_qr_block`.
- **Robust QR rendering helper** (`JoFotara_WC_QR`): accepts whatever JoFotara returns —
a data URI, an image URL, a base64 image, or raw QR content — and always yields a
displayable image (generating a QR via the bundled encoder for raw content). Used by both
the admin meta box and the PDF integration.
- **Sequential ICV invoice counter**: every invoice now carries a unique, incrementing
`ICV` counter (1→∞) as required by JoFotara, instead of the SDK default of always `1`.
- **wp-config constant overrides**: `JOFOTARA_WC_CLIENT_ID`, `JOFOTARA_WC_CLIENT_SECRET`,
`JOFOTARA_WC_SELLER_TIN`, `JOFOTARA_WC_SELLER_NAME`, `JOFOTARA_WC_SUPPLIER_INCOME_SOURCE`,
`JOFOTARA_WC_INVOICE_TYPE`, `JOFOTARA_WC_PAYMENT_METHOD`, `JOFOTARA_WC_TAX_RATE`,
`JOFOTARA_WC_ENABLED`, `JOFOTARA_WC_AUTO_GENERATE` now actually take effect.
- Bundled QR encoder: `lib/qrcode/qrcode.php` (TCPDF QRcode, namespaced to avoid collisions).
### Fixed
- Admin meta box QR code is now displayed correctly. It was rendered with `esc_url()`, which
strips `data:` URIs, so QR images never appeared.
- Line-item tax percentage is clamped to JoFotara's 16% maximum and protected against
divide-by-zero / out-of-range values that could make the SDK reject the invoice.
- Credit notes are now issued on the **cancellation date** (not the original order date) and
reference the exact original `cbc:ID` / `cbc:UUID` and total that were submitted.
- **Refund credit notes now reuse the original invoice's exact unit prices and line IDs**,
expressing the returned portion as a (possibly fractional) quantity — fixing the JoFotara
rejection *"The unit price must match the unit price in the original invoice"* that occurred
on refunds involving discounts or partial shipping (shipping is a single, quantity-less line).
- Customer city code is omitted when unknown instead of defaulting every customer to Amman.
- Activation now seeds the individual option keys the plugin actually reads (the previous
`jofotara_wc_settings` array was never used).
### Changed
- Invoice generator refactored to share customer/line-item building between sales and credit
invoices for consistency.
- Orders list column now also indicates when a credit note has been issued.
- WC tested up to 9.4.
- **Credit invoices (credit notes)**: a JoFotara credit invoice (UBL type `381`) is now
issued automatically when an order is cancelled or refunded — the feature that was
previously documented but never wired up.
- `woocommerce_order_status_cancelled` → full credit note mirroring the original invoice.
- WooCommerce refunds (`woocommerce_order_refunded`) → a credit note for the refunded
items/amount (supports partial refunds).
- Manual status change to "Refunded" with no refund object → full credit note.
- New manual order action: **Issue JoFotara Credit Invoice (cancel)**.
- Duplicate prevention: only one *full* credit note per order; partial refunds may each
get their own credit note. Stored in `_jofotara_credit_invoices` (+ latest in
`_jofotara_credit_invoice_data`).
- New hooks: `jofotara_wc_credit_invoice_generated`, `jofotara_wc_credit_invoice_generation_failed`.
- **Official JoFotara QR on PDF invoices**: the QR returned by JoFotara on a successful
submission is now injected into invoices generated by the WebToffee plugin
*WooCommerce PDF Invoices, Packing Slips, Delivery Notes and Shipping Labels* (via the
`wt_pklist_alter_final_order_template_html` filter), shown **only** when the order was
actually submitted to JoFotara. The WP Overnight PDF plugin is also supported
(`wpo_wcpdf_after_order_details`).
- Filters to customize: `jofotara_wc_webtoffee_document_types`, `jofotara_wc_webtoffee_qr_block`.
- **Robust QR rendering helper** (`JoFotara_WC_QR`): accepts whatever JoFotara returns —
a data URI, an image URL, a base64 image, or raw QR content — and always yields a
displayable image (generating a QR via the bundled encoder for raw content). Used by both
the admin meta box and the PDF integration.
- **Sequential ICV invoice counter**: every invoice now carries a unique, incrementing
`ICV` counter (1→∞) as required by JoFotara, instead of the SDK default of always `1`.
- **wp-config constant overrides**: `JOFOTARA_WC_CLIENT_ID`, `JOFOTARA_WC_CLIENT_SECRET`,
`JOFOTARA_WC_SELLER_TIN`, `JOFOTARA_WC_SELLER_NAME`, `JOFOTARA_WC_SUPPLIER_INCOME_SOURCE`,
`JOFOTARA_WC_INVOICE_TYPE`, `JOFOTARA_WC_PAYMENT_METHOD`, `JOFOTARA_WC_TAX_RATE`,
`JOFOTARA_WC_ENABLED`, `JOFOTARA_WC_AUTO_GENERATE` now actually take effect.
- Bundled QR encoder: `lib/qrcode/qrcode.php` (TCPDF QRcode, namespaced to avoid collisions).
### Fixed
- Admin meta box QR code is now displayed correctly. It was rendered with `esc_url()`, which
strips `data:` URIs, so QR images never appeared.
- Line-item tax percentage is clamped to JoFotara's 16% maximum and protected against
divide-by-zero / out-of-range values that could make the SDK reject the invoice.
- Credit notes are now issued on the **cancellation date** (not the original order date) and
reference the exact original `cbc:ID` / `cbc:UUID` and total that were submitted.
- **Refund credit notes now reuse the original invoice's exact unit prices and line IDs**,
expressing the returned portion as a (possibly fractional) quantity — fixing the JoFotara
rejection *"The unit price must match the unit price in the original invoice"* that occurred
on refunds involving discounts or partial shipping (shipping is a single, quantity-less line).
- Customer city code is omitted when unknown instead of defaulting every customer to Amman.
- Activation now seeds the individual option keys the plugin actually reads (the previous
`jofotara_wc_settings` array was never used).
### Changed
- Invoice generator refactored to share customer/line-item building between sales and credit
invoices for consistency.
- Orders list column now also indicates when a credit note has been issued.
- WC tested up to 9.4.
v1.0.1
2026-02-16
### Added
- Full HPOS (High-Performance Order Storage) compatibility declaration
- Enhanced meta box support for HPOS order screens
- Documentation about HPOS compatibility
### Changed
- Updated meta box registration to support both traditional and HPOS order screens
- Improved meta box rendering to handle both WP_Post and WC_Order objects
- Added `declare_hpos_compatibility()` method using WooCommerce's FeaturesUtil
### Fixed
- Resolved WooCommerce incompatibility warning when HPOS is enabled
- Ensured meta boxes display correctly on HPOS order edit screens
- Full HPOS (High-Performance Order Storage) compatibility declaration
- Enhanced meta box support for HPOS order screens
- Documentation about HPOS compatibility
### Changed
- Updated meta box registration to support both traditional and HPOS order screens
- Improved meta box rendering to handle both WP_Post and WC_Order objects
- Added `declare_hpos_compatibility()` method using WooCommerce's FeaturesUtil
### Fixed
- Resolved WooCommerce incompatibility warning when HPOS is enabled
- Ensured meta boxes display correctly on HPOS order edit screens
v1.0.0
2025-10-21
### Added
- Initial release of JoFotara WooCommerce Integration
- Automatic invoice generation when orders are completed or processing
- Admin settings page integrated with WooCommerce settings
- Manual invoice generation via order actions
- Invoice status display in orders list
- Detailed invoice information in order edit page meta box
- Comprehensive logging system with debug mode
- Support for multiple invoice types (General Sales, Special Sales, Income)
- Flexible payment method handling (Auto, Cash, Receivable)
- Integration with JoFotara PHP SDK v0.9
- WordPress and WooCommerce coding standards compliance
- Complete inline documentation
- Error handling and validation
- Order notes for invoice generation success/failure
- Custom order meta fields for storing invoice data
- HPOS (High-Performance Order Storage) compatibility
- WordPress 5.8+ support
- WooCommerce 5.0+ support
- PHP 8.0+ requirement
### Features
- **Automatic Invoice Generation**: Generates invoices automatically when orders reach completed or processing status
- **Admin Settings**: Comprehensive settings page for configuring credentials and invoice options
- **Manual Generation**: Generate invoices manually from order actions dropdown
- **Invoice Storage**: Stores complete invoice data in order metadata
- **Status Indicators**: Visual status badges in orders list
- **QR Code Support**: Displays QR codes from JoFotara in order details
- **Debug Logging**: Detailed logging for troubleshooting
- **Hooks & Filters**: Extensible via WordPress actions and filters
- **Error Handling**: Graceful error handling with user-friendly messages
- **Multi-language Ready**: Translation-ready with text domain
### Technical
- Plugin architecture following WordPress standards
- Class-based structure with singleton patterns
- Autoloading via Composer
- Proper sanitization and escaping
- Security best practices
- WPCS (WordPress Coding Standards) compliant
- Comprehensive inline documentation
### Security
- Input validation and sanitization
- Output escaping
- Nonce verification for actions
- Capability checks for admin functions
- Secure credential storage
- No hardcoded credentials
- Initial release of JoFotara WooCommerce Integration
- Automatic invoice generation when orders are completed or processing
- Admin settings page integrated with WooCommerce settings
- Manual invoice generation via order actions
- Invoice status display in orders list
- Detailed invoice information in order edit page meta box
- Comprehensive logging system with debug mode
- Support for multiple invoice types (General Sales, Special Sales, Income)
- Flexible payment method handling (Auto, Cash, Receivable)
- Integration with JoFotara PHP SDK v0.9
- WordPress and WooCommerce coding standards compliance
- Complete inline documentation
- Error handling and validation
- Order notes for invoice generation success/failure
- Custom order meta fields for storing invoice data
- HPOS (High-Performance Order Storage) compatibility
- WordPress 5.8+ support
- WooCommerce 5.0+ support
- PHP 8.0+ requirement
### Features
- **Automatic Invoice Generation**: Generates invoices automatically when orders reach completed or processing status
- **Admin Settings**: Comprehensive settings page for configuring credentials and invoice options
- **Manual Generation**: Generate invoices manually from order actions dropdown
- **Invoice Storage**: Stores complete invoice data in order metadata
- **Status Indicators**: Visual status badges in orders list
- **QR Code Support**: Displays QR codes from JoFotara in order details
- **Debug Logging**: Detailed logging for troubleshooting
- **Hooks & Filters**: Extensible via WordPress actions and filters
- **Error Handling**: Graceful error handling with user-friendly messages
- **Multi-language Ready**: Translation-ready with text domain
### Technical
- Plugin architecture following WordPress standards
- Class-based structure with singleton patterns
- Autoloading via Composer
- Proper sanitization and escaping
- Security best practices
- WPCS (WordPress Coding Standards) compliant
- Comprehensive inline documentation
### Security
- Input validation and sanitization
- Output escaping
- Nonce verification for actions
- Capability checks for admin functions
- Secure credential storage
- No hardcoded credentials