PDF invoice: order totals calcualted differently depending on location in invoice?

[30knees]

The reason I'm asking is because an invoice I opened shows two different totals, see below. I don't know where the price discrepancy would come from. I edited the shipping price from 20 to 18.18, but that's not the difference between the two totals.

[datakick]

4 minutes ago, e-com said:

The ability to generate a PDF invoice has nothing to do with whether the order is paid or not. In configuration of order statuses we can set that for all statuses it is possible to generate a PDF invoice.
However, module you are using is bugged and incorrectly updates data of the PREFIX_order_payment table. And now you have inconsistent data in database tables.

Actually, when you generate invoice, and no payments are recorded yet, system will create new payment record.

https://github.com/thirtybees/thirtybees/blob/8b522e19ccaadd1ba6570d5d853628bd7f471ed8/classes/order/Order.php#L1590

There is a comment in code:

Since an invoice always requires an existing order payment, we are going to add one

Looks like thirty bees does not support unpaid invoices???

Anyway, if you modify the order after the payment is recorded, you should record additional payment (possibly negative) 

All payments will be displayed on invoice, making it match

 

 

[30knees]

I discovered that when one generates an invoice the system thinks the order was paid (even if you don't change the order state to a state that is paid but leave it unpaid). This is the order total that shows up above as 431,95.

I edited the order I had generated the first invoice because the customer requested some changes. I then deleted the old invoice and generated a new one. The 431,95 was taken from the old invoice.

[e-com]

By default, it is not possible to change delivery cost for any of the order statuses.
It looks like you have some module that enables this. And in this module you should look for errors of incorrect update of order value.

[30knees]

Correct, I have a module to edit orders. 🙂 But I guess that's still independent of the issue that when one generates an invoice the system thinks the order was paid (even if you don't change the order state to a state that is paid but leave it unpaid).

Edited February 9, 2023 by 30knees

[e-com]

The ability to generate a PDF invoice has nothing to do with whether the order is paid or not. In configuration of order statuses we can set that for all statuses it is possible to generate a PDF invoice.
However, module you are using is bugged and incorrectly updates data of the PREFIX_order_payment table. And now you have inconsistent data in database tables.

[30knees]

Does that make sense, no invoice without a payment? It depends on your type of accounting but it feels like it shouldn't be decided by the shop.

[datakick]

15 hours ago, 30knees said:

Does that make sense, no invoice without a payment? It depends on your type of accounting but it feels like it shouldn't be decided by the shop.

It make sense in B2B mode. Not so much in B2C

[wakabayashi]

20 hours ago, datakick said:

Looks like thirty bees does not support unpaid invoices???

Yeah there are some issues with it. I remember, that I have at least outcommented the following:

if ($orderStatus->logable && (string) $cartTotalPaid !== (string) $amountPaid) {
	$idOrderState = Configuration::get('PS_OS_ERROR');
}

in validateOrder() of PaymentModule.php

But surely that is not a clean solution. In general this problem is also a bit related to a messy order status handling. (These kind of problems are also known by our loved brother: https://github.com/PrestaShop/PrestaShop/discussions/31038)