on
RE:
The ironic thing here, is that having tried to move to new improved microsoft tech, the only solution is to export as two documents, and then write a VBA script to merge the files en masse! This is not where we should be.
RE:
Any update on this? I've not seen this listed on any of the release plans for Fabric.
RE:
My current Power BI version is Version: 2.128.952.0 64-bit (April 2024) in case you need that information.
RE:
We use apps as our preferred content delivery method at my organization to allow us to customize content to different groups based on their audience. Having the ability for users to favorite a report inside an app would allow them to use the same functionality that is available to users who navigate directly to a report outside of an app.This would be extremely helpful for our users, who appreciated being able to favorite reports when that was our standard delivery method (prior to pivoting to apps). This is functionality that they have now lost since we've made the switch to apps.Thanks,James Woodward
RE:
I'm looking for this for ages, please, get this the attention it deserves!
RE:
It would be nice when this will be possible in a for/foreach loop as well
RE:
I see that the link to https://learn.microsoft.com/en-us/dynamics365/release-plan/2024wave1/commerce/dynamics365-commerce/planned-features no longer mentions batch tracking being available in 2024 Release Wave 1. Did this get dropped ot planned for the future release?Please respond as we are planning to utilize this new feature for one of our customers.
RE:
We have done the same as Shannon.
RE:
Actually, I think this is an application bug because if I have one or more dimensions as mandatory [Default Dim Account Type - Table 15 G/ Account - Posting Value = Required Code], when I execute the VAT calculation, I need to change this parameterization. So, this is a problem: the general ledger entries run out of dimensions, which causes problems in financial reporting due to the lack of dimensions that should be mandatory. And, customers will change an important setting which in itself is not a good solution either.
RE:
Agreed. Unless MS can figure the scalability thing out first for us :) Although current roadmap developments (query scale-out and auto-scale) do help with scaling up for higher concurrent user rates, scaling up for faster interactive query performance remains out of reach - leaving smaller teams unable to 'buy some time' to optimize reports while still being able to deliver reports in a timely and non-aggravating manner to end users. Although there is the inherent limitation from the Vertipaq engine presented by the FE engine (which can only use 1 stream and 1 core at a time and therefore cannot be sped up), it is disheartening that even a high-SE engine-based query is not 'scalable' when additional capacity is purchased (meaning it will not speed up its performance by maximizing parallelization or automated temp SE aggregations or whatever other magic could be worked). If PaaS would offer us the ability to develop this functionality in-house, then at least our extensive optimization efforts will be seen to save time AND money :)Also - I am open to any other options, tools, work arounds or viewpoints that might help us 'scale up' slow queries, understanding that optimization is already being worked on heavily and continuously, and the hiring pool for folks who can reliably optimize DAX (and return valid results) is not very large. The goal here really is to enable a system where, when a query isn't fast, we can just throw some money at it until next month.If the VertiPAQ engine truly cannot be speed up by increasing resources, then a report which highlights which portions of current capacity usage are not scalable down to the per-query level and relevant statistics on how often the worst-performing queries are run and their total capacity impact would be much appreciated - the current Capacity usage metrics report does not get us there (or even in the neighborhood). Thanks for reviewing!