force_qty error when syncing Shopify orders into Odoo 19: what it is and how to fix itIf you migrated to Odoo 19 and your Shopify connector crashes on importing an order with an unexpected keyword argument 'force_qty' error, you are in the right place. Here we explain the real cause, why it is not your stock configuration's fault, and how it is fixed properly.
When Odoo 19 tries to process the order coming in from Shopify, the traceback always ends on this line. It is the literal text you probably searched to land here:
TypeError: StockMove._action_assign() got an unexpected keyword argument 'force_qty'It is not random. It shows up every time an order touches the connector's forced / partial reservation path. If an order reserves on its own without going through that logic, it does not fail — which is why it can look intermittent.
It is not a mystery, and it is not a bug in your Odoo. It is a core signature change that an outdated connector has not caught up with yet.
On Odoo 17 and 18, StockMove._action_assign() accepted a force_qty parameter to force the reservation of a specific quantity. On Odoo 19 that argument was removed from the method's signature in the stock module.
A third-party Shopify connector built for v17/18 keeps executing _action_assign(force_qty=...). Python does not find that argument in the new signature and raises the TypeError. It is connector code, not your stock setup.
The error surfaces when the order enters the connector's forced or partial reservation path (typically on confirming the order or creating the delivery). That is why some orders come in fine while others crash.
In one sentence: your Odoo 19 is fine; the Shopify connector still speaks the v18 dialect. As long as it keeps passing force_qty, any order hitting that path will keep crashing.
Order matters: first you unblock operations, then you apply the real fix. What you must never do is patch core.
The correct fix is a connector actually built and tested on Odoo 19. The module's author needs to drop the force_qty argument: on v19 you reserve by setting the move's quantity and calling _action_assign() without that parameter. Until the connector makes that change, the error will keep coming back.
# Odoo <= 18 (the old connector — what crashes on v19)
move._action_assign(force_qty=qty)
# Odoo 19 (correct signature — no force_qty)
move.quantity = qty # quantity is set on the move
move._action_assign() # reserves without the removed argumentIt is tempting to write a monkey-patch and put force_qty back into StockMove._action_assign(). Don't. You are manually reintroducing a signature Odoo removed on purpose, you will break on every minor update, and you fall out of support. The problem lives in the connector; it gets fixed in the connector.
To unblock a stuck order right now, go to the delivery in Odoo and reserve it manually ("Check availability" / assign the quantities). By reserving it yourself, the flow never enters the connector's forced-reservation path, so the call with force_qty is never triggered and the delivery moves forward. It is an operational stopgap while the updated connector arrives.
Important: the step-3 patch unblocks orders one by one, but it does not fix the underlying cause. Every new order that touches forced reservation will crash again until the connector stops passing force_qty.
At FlexigoTech we maintain a Shopify connector for Odoo that is built and tested on version 19. It reserves stock with the current API, no force_qty, so this TypeError never shows up. It covers orders, products and variants, two-way stock, fulfillment and tracking, and stays current with every Odoo release.
We are not selling you a miracle. We are a developer in Barcelona who builds and directly supports the connector, no reseller in between. If you're hitting this error, we can take a look and tell you whether our module fits or whether the better move is fixing your current connector. A technical answer, not a sales pitch.
Whether you want a connector already built for v19 or you need someone to fix yours, here are the routes.
No. The error does not depend on your routes, warehouses or replenishment rules. It is caused by the Shopify connector, which keeps calling _action_assign(force_qty=...) the way it did on v17/18. In Odoo 19 that argument no longer exists in core, so Python raises the TypeError. Your stock configuration is correct.
Not advisable. Putting force_qty back into StockMove._action_assign() with a monkey-patch manually reintroduces a signature Odoo removed on purpose, breaks on every minor update, and leaves the install unsupported. The correct fix is for the connector to stop passing that argument. Core stays untouched.
As a temporary fix you can reserve the affected order manually from the delivery in Odoo ("Check availability" / assign the quantities). Reserving it yourself keeps the flow out of the connector's forced-assignment path, so the call with force_qty is never triggered and the delivery moves forward. It is an operational patch, not the underlying fix: the connector still needs updating to the Odoo 19 API.
Yes. FlexigoTech's Shopify connector is built and tested on Odoo 19, reserving stock with the current API without using force_qty. It covers orders, products and variants, two-way stock, fulfillment and tracking, and stays current with every Odoo release. It is developed and supported directly by a developer in Barcelona, with no reseller in between.
If your Shopify connector crashes with force_qty, you can switch to our module tested on v19 or ask us to fix yours. We'll tell you with technical judgment, no smoke and mirrors.