Rune Rasmussen

Thank you for noting the typo, we will update the next release!

Such typos can have negative effects, when the updates are being flagged wrongly, so better ensure it not happens again.

Regarding the PHP requirements we’ve already set the requirements to 8.0 as you mentioned so it’s not included in the patch notes.

Yes, but you also have said it can be installed manually on lower PHP versions.

Anyhow it was the addition of the required dependencies I had in mind, that you should have noted. ??

Using 2 decimals is standard practice when handling money since it’s the smallest amount that you can pay with. You could for example pay 1.23 NOK but you can’t pay 3.456 NOK.

Sure, but it’s not standard in shops in the Nordic countries etc. I think you’re being well aware of that. ??

Most displays and handles prices like 2200,-
T.ex. like the “small” shop https://www.elgiganten.se

In our previous answer that you’re referring to we didn’t say that tax had to be used but rather that in order for tax calculations to be correct there is a need for two decimals.

Sorry, that clearly was a typo, which the overall post should tell.

Anyhow let’s get back to the real issue, which is that most web shops don’t want to display decimals, and that this should and could be handled better for those shops. ??

Or would you claim it’s impossible to get the tax class/value/rate directly, together with the prices excluding tax? Or in any other way calculating it correctly?

*AND not to forget, the issue regarding your missing documentations.

• This reply was modified 6 months ago by Rune Rasmussen.

Feel free to ask, and we can mail it if it’s sensitive.

Anyhow this seems to possibly be related to Svea sending two validation callbacks, according to your plugins log – that’s one thing sticking out. And the interesting question is probably how the plugin handles this in such cases.

Anyhow I’ll mail you the full log for this latest order, and you can ask Svea about what happened in their end, and then see how it can be handled in the plugin.

How on earth should we reproduce something happening now and then between Svea API and Svea Checkout for WooCommerce, please tell us if you have some ideas on how to do that, or rather ask for any info that we actually could provide regarding the issue…

Anyhow, here’s what your plugin has logged for the latest incident. It’s not much you’re logging, but seems strange with two validations etc.

2024-05-27T10:29:10+00:00 NOTICE Validation callback successfully made for order #18… (ID: 28…) CONTEXT: {“_legacy”:true}
2024-05-27T10:29:10+00:00 NOTICE Sending validation response: array (
‘Valid’ => true,
‘Message’ => ”,
‘ClientOrderNumber’ => ’18…’,
) CONTEXT: {“_legacy”:true}
2024-05-27T10:30:01+00:00 NOTICE Validation callback for Svea order ID (67…….) received CONTEXT: {“_legacy”:true}
2024-05-27T10:30:02+00:00 NOTICE Processing checkout for Svea Order ID: 67……. CONTEXT: {“_legacy”:true}
2024-05-27T10:30:03+00:00 NOTICE Validation callback successfully made for order #18… (ID: 28…) CONTEXT: {“_legacy”:true}
2024-05-27T10:30:03+00:00 NOTICE Sending validation response: array (
‘Valid’ => true,
‘Message’ => ”,
‘ClientOrderNumber’ => ’18…’,
) CONTEXT: {“_legacy”:true}
2024-05-27T10:30:10+00:00 NOTICE Syncing order rows. Order ID: 28… CONTEXT: {“_legacy”:true}
2024-05-27T10:30:10+00:00 NOTICE Push callback finalized order. Svea ID:67……. OrderID: 28… CONTEXT: {“_legacy”:true}
2024-05-27T11:47:11+00:00 NOTICE Cancel order: array (
‘OrderId’ => 67…….,
) CONTEXT: {“_legacy”:true}

No, there is non such plugins.

Also this is just an issue now and then, if it was every order it could be a plausible place to look, but it’s not the case here. I would say it’s some signals between Svea Checkout API and Svea Checkout for WooCommerce who is being mixed up / handled wrongly for some orders – and that’s where we should start looking for the cause of those issues.

Downgrading from 2.7.2 to 2.6.5 seems to solve it.

Since it’s not mentioned in the change log for later versions it’s unknown if it have been tried handled there, and whether it works then.

@thegeneration it’s clear that you have added your own order status, the ‘Awaiting status’.

For this you also have added your own mail sending code, informing the customer about this specific status, right.

@dlind confirmed this was the order status before it went on to processing, thus it’s clearly similar to what other also have experienced, and thus this custom status then is the most plausible cause for it.

Also since you wrote above:

If a order goes from “Awaiting status” it’s possible that the confirmation email wont be sent.

By this you basically says this custom status added in your plugin is the plausible cause for not sending the confirmation yourself also.

And anyhow you doesn’t seem to have any mailing to the store owner for this custom order status, only to the customer, and they most likely doesn’t get the confirmation copy either then if there is no trigger between your custom ‘Awaiting status’ and the ‘Processing’ status.

Just my 5 cents.

@dlind – I just want to ask one question here…

So it has transitioned from “Pending Payment” to “Processing”.

In the order view, have you confirmed this, or is it just a guessing? There’s a meta box displaying a change log for the orders on the right side in the order details view (normally), can you please confirm it actually had the “Pending Payment” status before it got into “Processing”, and not “Awaiting status” or anything else?

@thegeneration – regarding your reply here:

If a order goes from “Awaiting status” it’s possible that the confirmation email wont be sent. However the customer should receive an email regarding the order and its status.

Honestly I don’t think this is good enough. You added this status in the module, and you also have added your own mailing code for it. You should know how it works, and if it works correctly, and not just be guessing.

If there isn’t any mail being sent to the store owner it’s a problem for some of them, who like to get a mail notifying them about new orders. So better check it, and sort it out.

Not want to hijack the tread, but we’ve seen the same happening recently, and I’m pretty sure it’s related.

It happened when the order waited for status from Svea (Awaiting status), which is a specific status for Svea Checkout I guess, and thus I also suspect it’s what caused it.

• This reply was modified 6 months, 2 weeks ago by Rune Rasmussen.

Sure, but with all that said, let’s face that it was a bad advice in this case anyway. ??

However, could you kindly check if you have any pending orders to sync in WooCommerce > Settings > Advance > Feature? If there are any, please click on “sync pending order” and let the sync process complete.

Sorry, to break in, but why should we actually do that? This seems like a bad advice to me …

On a new store running HPOS I don’t see why anyone should synchronise the orders to the post table, that would only slow things down, and what’s the point of using HPOS then. I also strongly assume that the syncing and no HPOS mode will be removed at some point, so better make the widget also compatible with HPOS only.

If syncing to the post table still is required for core Woo, that should be automatically activated with HPOS then, to ensure proper functionality of the system for new stores.

Just my 5 cents. ??

Note! Just for the record, it seems solved in Woo 8.8+

Yes, it’s the default behaviour in spite of what’s stated here.

Only way to get it correctly displayed is to use the shortcode, so the automatic replace function isn’t useful.

Thanks,

I don’t recall the step exactly anymore. I did import the subscribers before I imported the customers (webshop migration), but I don’t recall if the customer had been imported when I tried to delete the subscribers. Thus it’s plausible that it’s linked to the customers, and how MailPoet works regarding this.

I don’t agree it’s optimal the way MailPoet handles subscribers though (honestly it’s a bit annoying), and hopefully that will be reworked at some point, but that’s anyhow a different matter, so we can leave it there – assuming you’re right about the linked customers/users.

PS! Anyhow MailPoet should display a error/note about what’s going on, and not just reload or redirect without doing anything, leaving us users wondering just like that… ??

• This reply was modified 7 months, 3 weeks ago by Rune Rasmussen. Reason: Added PS

Thanks, I understand. Looking forward to the reworked email designer then. ??

Thanks, got it working then.

The locale should be nb, for both nb and no (both is Norwegian Bokm?l).

	'nb' => 'nb',
	'no' => 'nb',

Note! Also tested nb_no who didn’t work.

https://developers.deepl.com/docs/resources/supported-languages