Recently updated to the build 21.216.0034. It would appear there has either been some change to what triggers a ‘Product Availability’ sync request, or otherwise a related bug.
In previous builds, ‘Product Availability’ record prepared of course based on update to the given inventory ID (Template, Stock, Non Stock). Expected and documented functionality. Since our update to this build last week, it appears that nearly all Inventory ID records are entering the prepare/process queue, even though the majority of those records have not been modified by any expected action (ie, sales order created, PO received, inventory adjustment, etc).
Is this a known situation? Have changes to what triggers a product availability request been meaningfully changed in this build?
Why this matters in our integration: We override the ‘track inventory’ setting for BigCommerce products that we want to allow backorder on (ie, take an order for something not in stock). For items with low velocity, the Inventory ID is rarely adjusted and the BigCommerce settings hold (until the point the Inventory ID has a product availability related action in the internal system). With the new behavior since the build update, hundreds of records that have had no meaningful change to stock on hand are now cycling through on a daily basis and require more routine overrides on the BigCommerce side.
Any insight here is appreciated. We’re actively working on a new solution to our inventory script that makes the BigCommerce adjustments in real time (vs a CSV upload to override), but we need to understand this new behavior to ensure we’re designing the right solution.
Best answer by PhilView original
In general, there was no changes in the logic for the product availability. Connector looks at the 3 tables(INSiteStatus, INLocationStatus, InventoryItem) for the LastMofidiedDateTime. In case any of them is updated, we have to resync.
Related to what has been changed… may be you have any business event or import scenario or API call that triggers an update? Or may be availability calculation settings forces Acumatica to recalculate INSiteStatus, INLocationStatus.
Related to the low velocty items. May be as a work around you can put for the Availability = Do no update? Then you don’t really need sync their availability.
Our mistake - my colleague ran a big mass records update which, though it did not seem like it would impact availability, pushed all records into the product availability sync queue. Simple explanation to what occurred!
Thank you for sharing the resolution