RE:
Absolutely agree. I can see "Created On" and "Modified On" in my local timezone, but "Journey Start Time" is in the default timezone (not even sure which one), which could definitely lead to mistakes.
RE:
This is causing a lot of confusion for clients and even consultants, please, it is as simple as adding the two fields mentioned at the end Connor.
RE:
I don’t know why this idea has been rejected because it seems very interesting. Since it’s not possible to interact with the existing columns via AL, at least the system should allow hiding those that are not useful, such as the sales price.
RE:
We use Power BI in combination with SQL Server. For many of our tables, we maintain system versioning, which allows us to "travel back in time." The point in time to travel is selected by the user, leaving us with a few options:Import History Tables into Power BI:This approach places significant pressure on infrastructure due to the large size of the tables and results in a poor user experience. Additionally, we lose near real-time data freshness and nice sql syntax "FOR SYSTEM_TIME AS OF ".Use M Parameters with SQL Query Manipulation:This setup involves manipulating SQL queries as strings. While it can be done, it is super obscure way that makes sense only for very simple "SLECT * FROM " type of queries. Something a little more complex will be very difficult to write, read, change, and test.Fallback to SSRS Reports:Currently, this is our chosen solution.The same logic applies to any situation where a large amount of data for fetching could be significantly reduced by applying user selection.We aim to phase out SSRS and fully adopt Power BI. However, Power BI still lacks features to effectively supersede SSRS in scenarios like these. Is there a plan to address this limitation and improve the situation?
RE:
Great idea!
RE:
Please fix this ASAP!
RE:
Completely agree with above. You can achieve it quite easily with a little bit of code. Please spend the 15 minutes it takes to do this. This is the time it takes for a developer to make this happen. I've just done it myself using events.Also, from an accounting point of view, I have a hard time understanding why it's not running the postings from a report that you have to call like it was done with "Calculate Depreciations" - this is really bad design accountants perspective.
RE:
Agree!!!
RE:
Why system allowed delete vendor postdated check with staus "posted"?