PSv8.1.6 Printing Invoices no longer works BO/Orders/Invoices

[gray]

PSv8.1.6 Printing Invoices no longer works BO/Orders/Invoices

By order status or by date get an error message (Division by Zero)

See error message and debug screen

[gray]

Just printing out all orders individually from the order page.

All OK until I got to about 40 orders, then I got the same error message.

Went to order 41 and it printed out fine. Went back to order 40 and error.

So I must assume that order in 40 there must be something corrupt. Not got time to look into yet.

[wepresta]

Hi,

That error is the key part:

“No route found for GET … /sell/orders/invoices/by_status – Method Not Allowed (Allow: POST)”

In PrestaShop 8.1.x, the “Print invoices” actions are sent as a POST request (with a token/CSRF). If your shop is calling that URL with GET, PrestaShop will refuse it and you end up on the Symfony error page.

What usually causes this:

• Back-office JavaScript is not loading / broken
  • If the JS is broken, buttons can behave like simple links (GET) instead of submitting the form (POST).
  • Open the invoice page, press F12 → Console, and check if there are red JS errors.
  • Temporarily disable browser extensions (adblock, script blockers) and test again.
• A module/override is breaking the back office : Disable modules that inject things into BO (security, optimization, “back office enhancements”, checkout tools, etc.) and test again.
• Cache issue after update
  • Advanced Parameters → Performance → Clear cache 
  • If needed, delete /var/cache/ (dev + prod) via FTP/SSH and reload BO.
• Bug fixed in a newer patch : If you recently updated to 8.1.8, update to the latest 8.1.x patch (or 8.2.x if possible). These invoice/BO issues are often patched in maintenance releases.

If you want one simple test: try the same action in a clean browser session (incognito + no extensions). If it works there, it’s almost certainly JS/extensions. If it fails everywhere, it’s usually a module/override or a core bug fixed by updating.

[gray]

So why does it print each individual order out perfectly OK, via the order page ? except for one order.

But with specific order, no 40 I get the same error message.

Go to order 41, and it prints out OK. Go back to order 39 and it prints OK

In fact, all orders from 1 to 39 and 41 to 100 all print out individually perfectly.

Somewhere in order 40 it is corrupt.

My suspicions are that there is nothing wrong with the 'print invoice' software. But the error is somewhere in this single corrupt order.

But when I say there is nothing wrong with the software, there is, but it is due to not having correct error handling to handle the corrupted order.

I do not have time to look into this order for errors, until all my orders are shipped. I believe if I delete this order it will clear the invoice printing problem.

Any thoughts please.

[wepresta]

If only order #40 triggers the error while all other orders print fine, then yes: it’s very likely something inside that order data is breaking the invoice generation (bad address field, invalid characters, missing invoice number/date, corrupted customer data, etc.). Deleting the order may “hide” the symptom but it’s risky (audit trail, numbering, accounting).

Quick workaround :

• Try printing the invoice for #40 from the Invoices page (Orders → Invoices) instead of the order page.
• If you must ship now: disable invoice generation for that order, ship it, then fix the order data after.

Fast check (5 minutes):

• Open order #40 and edit/save the addresses (delivery + invoice) without changing anything (forces data re-save).
• Check customer/company/VAT fields for weird characters (quotes, emojis, line breaks).
• Verify the order actually has an invoice number assigned.

Also, the route error (“GET… Allow: POST”) can still be caused by BO JS not submitting properly, but if it happens only on one order it strongly points to a data edge case.

If you paste the exact invoice generation error from logs (or enable debug just for this test), we can pinpoint the field that breaks it.

[gray]

Ok a little bit more info. The one affected order is actually the only one that has been cancelled.

In just limiting invoices 'by date' to a very narrow range ie 3 days it prints out all for that period including the cancelled order.

But entering a wider date range ie 4th April 2025 to 29th Dec 2025, it throws the error.

In just generating invoices 'by order' status and using 'payment accepted' it throws the error.

 

[wepresta]

Two quick things to check:

• Does the cancelled order actually have an invoice?
  • Open the order → Documents. If there’s no invoice number/date, exclude it from invoice generation.
• In Orders → Invoices, try generating:
  • by date with “Only orders with invoices” (if available), or
  • by a status that only includes orders that should have invoices (e.g. Payment accepted), and make sure the cancelled order is NOT in that selection.

If it still fails “by status”, it means the cancelled order is still being included in that status filter (or has inconsistent state/history). Easiest fix is to set the cancelled order to a proper non-invoice state and ensure it’s not in “Payment accepted”.

If you want a fast workaround now: temporarily exclude cancelled orders from invoice batch, ship your orders, then we can identify the exact field in that cancelled order that breaks the generator.

[gray]

When you view the order, I am able to view the invoice with invoice and order number, and it still shows the payment and shipping method. No mention on it saying 'cancelled'.

With PS 8.1.6 Only able to display orders by date range only or order status only.

Obviously with the latest version of PS, this problem may not occur.

 

 

 

 

[wepresta]

6 minutes ago, gray said:

When you view the order, I am able to view the invoice with invoice and order number, and it still shows the payment and shipping method. No mention on it saying 'cancelled'.

With PS 8.1.6 Only able to display orders by date range only or order status only.

Obviously with the latest version of PS, this problem may not occur.

 

 

 

 

If the invoice exists and looks normal inside the order, then the issue is probably not “missing invoice”, but a batch-generation edge case (usually one order record in that range breaks the PDF generation), and the “GET vs POST / Method Not Allowed” message is just the symptom.

If you can paste the exact PDF generation log (enable debug just for that action), we can pinpoint the exact field causing the crash.

[gray]

1 hour ago, wepresta said:

If you can paste the exact PDF generation log (enable debug just for that action), we can pinpoint the exact field causing the crash.

Where exactly is this located, and the file name please?

[El Patron]

This is not a server issue, not permissions, and not PHP config.
It is a core BO controller / routing mismatch introduced in PS 8.1.x.

However, the Back Office UI triggers this route via a GET request when clicking:

• “Print invoices by status”
• “Print invoices by date”

So Symfony blocks it correctly with HTTP 405 Method Not Allowed.

This is why:

• Debug mode shows a Symfony exception
• Non-debug mode shows a generic BO error
• It affects all environments consistently

Patch the controller to allow GET only for BO invoice generation.

find file

/src/PrestaShopBundle/Controller/Admin/Sell/Order/InvoiceController.php
 

Locate the action handling byStatusAction() or byDateAction() and ensure it accepts both methods:

update as follows:

#[Route(
    '/sell/orders/invoices/by-status',
    name: 'sell_orders_invoices_by_status',
    methods: ['GET', 'POST']
)]