We are using lightspeedhq to manage our stocks between our physical store and our woocommerce webshop.
We translated our webshop using wpml in English and German, our default language is Dutch.
Recently we noticed that orders placed on our translated version of our site is not being synced to our lightspeedhq system.
The cause of this can be that wpml creates duplicates of our products for the translation and that this does not work together with lightspeedhq.
Could you let me know if there is a workaround for this?
Hi,
Lightspeedhq recommended me to create a new trail account with them.
Then I can link that to our staging site temporarily for testing.
I wil let you know when this is set-up.
Hi,
I have set-up a seperate trail account for Lightspeed and connected it with our staging site.
I created a new test product and placed an order through our default language NL and English.
The default language order is synced to Lightspeed.
The English language order is not synced to Lightspeed.
Which confirms the problems lies with WPML and Lightspeed compatibility.
This causes a difference in stock and reporting between Woocommerce and Lightspeed.
As we use Lightspeed also for our physical store this can give major stock issues when we have multiple orders from our translated versions of our webshop.
Let me know what you need access wise to test this?
I could see and test the issue. One thing is not clear to me, I do not see Lightspeed POS for WooCommerce plugin on your stating site, so how did you connect your staging website with POS system?
I am just trying to understand full picture before escalating this further.
Thank you for the details. I’m not entirely sure whether this is the same approach as using their plugin directly, since we officially support the plugin, but I’m not certain about their REST API–only integration and how it works from their side.
Do you simply share REST credentials with them, or is there an additional setup? As far as I know, our WPML/WC REST API works correctly, as explained here:
This plugin might help, and it would also give us a clearer picture when debugging. At the moment, if the communication is happening only via REST API, probably the best we can do is check whether the REST API responses from your website are correct and whether the order can be retrieved properly in both languages.
To addition to that.
The core problem now is that WPML creates different IDS for our translated products.
And it seems that Lightspeed can't process that as those products are not in our Lightspeed account, only the default language one.
This is also something their support mentioned.
1) Sure, please check with them and let me know how it goes. As mentioned, I can verify whether the REST responses on your staging site are correct and can be fetched, but I’m not familiar with how they process that data on their end or whether they fetch and include translated products. Using plugin would probably be a correct way here, and then we can check what is wrong and why 2nd language orders are not sent to their side.
2) Regarding different product IDs — yes, that is the expected behavior with WPML. This applies not only to products but to all post types. A new post / product is created for each language, with its own ID, and then linked to the original as its translation. I am afraid that is how WPML works in general, not something that can be adjusted or changed.
As said above, maybe plugin is the solution here, as it should have integration for WPML and for translated products etc.
Let me know what they say, and let's then decide from there on our next steps.
Lightspeed says it does not support the plugin you mentioned.
As it is from a different party.
It can cause the same issue and maybe also other issues they said.
I asked their support if there is then no other set-up possible that could fix this.
Let's see what they say.
They do keep saying it is just because of the different ids and not giving an attempt for a solution so far from their end.
1) I wasn’t aware this was related to a third-party solution — I initially thought you were referring to their plugin.
In this case, it would be best to check with the plugin author to confirm whether it supports the functionality you need, how it processes the data, and whether its behavior is suitable for your use case.
2) As mentioned, I’m not sure how their system handles data solely through the REST API. The issue could indeed be related to different IDs, but I’m not certain how we can assist with that. Our REST API works as expected and correctly returns different products, orders, and so on. It’s likely that further adjustments would be required on their end to ensure proper compatibility with WPML — and based on the replies so far, it doesn’t seem they intend to implement that. This might even be the reason that dedicated plugin was developed in the first place.
I’m sorry the conversation went in this direction and giving you wrong expectation. I was under the impression from the beginning that you were using that plugin, in which case we could have checked it and communicated with the plugin author directly if any bugs. I wasn’t aware the integration was done exclusively through the REST API.
See below their response on my question if any other set-up can fix this issue:
I was checking this with my team further, and they have confirmed that the only way to resolve this would be to find a translation plug-in that does not generate different product IDs per translation.
Unfortunately, we have not been able to identify such a plug-in on our end.
