Comments
We hit this same issue constantly - hundreds of Shopify exchanges/returns each requiring the same manual unlink → resolve conflict → recreate invoice steps. It's a huge time sink and error risk at our volume. We're actually considering a custom workaround just to avoid this, but would much rather see an automated/bulk conflict-resolution option added to the standard connector. Please prioritize this.
We've run into this exact issue while reconciling applications across our dev, UAT, and production environments - the same first-party app sometimes shows up under a completely different name depending on which package version is installed (e.g., "App profile manager" vs "Appprofilemanager"). It makes it really hard to confidently confirm we're aligned across environments without manually cross-checking or opening a support ticket. A stable identifier alongside the display name, plus a clear in-product indicator when a name difference is just due to a package version, would go a long way. Even just knowing an update is available and what it changes would help us plan rollouts with more confidence. Would love to see this prioritized since it adds real administrative overhead every time we do an environment comparison.
The current configuration is global per entity and applies the same task count to every execution above a single threshold, regardless of the actual volume or legal entity.For example, with a threshold of 200 records and a task count of 8:An import of 20,000 products creates 8 tasks of roughly 2,500 records each, where parallel processing is likely beneficial.An import of 2,000 products also creates 8 tasks, now with only around 250 records each. This consumes the same batch/AOS capacity while potentially adding more scheduling and partitioning overhead than performance benefit.A more adaptive design could support either:Multiple volume bands per entity, such as 2 tasks above 400 records, 4 tasks above 1,500, and 8 tasks above 10,000; orA target records-per-task value combined with a maximum task count.This would allow DMF to calculate an appropriate degree of parallelism for each execution rather than treating every import above the threshold identically
This feature / function is required not only for Intercompany orders but also how all purchase returns (real purchase returns or purchase order with negative qty) are handled in WMS App. We need function to release to warehouse lines which have a 'negative' (stock removal) indication. This should work in similar way how the Sales Pick / Put work - just that the reference has to be of a 'Vendor ID' instead of a 'Customer'. Do you have any news or currently this is in MS roadmap? Thanks in advance.