Comments
Highly needed to increase the flexibility of API responses. Currently it is very hard to create a performant API response when data has to be aggregated from multiple sources due to limitations in both the Query and Page API types. One addition I would like to make here is that it would be really beneficial to have complete access to the HTML request. We have the HTTP Client Object for outgoing calls but there is nothing equivalent for incoming ones.
Hello,We confirm the unit of measure issue in Business Central.Following tests carried out on different versions of Business Central, we have identified a display issue related to the item unit of measure.The base unit of measure for the item is defined as PU (unit), with a conversion of 1 box = 25 units: A transfer order was validated for 4 boxes, corresponding to a total of 100 units:The entries correctly calculate the quantity based on the base unit (100 units):In the warehouse entries, the displayed quantity is 100 with the unit PU, which is correct. In the item ledger entries, the quantity is also 100, which is correct.However, the unit displayed in the item ledger entries is "box", which is incorrect. The unit should be PU.This issue has been observed not only for transfers but also for purchase transactions.
I would like to emphasize while this is an important improvement from a performance perspective Currently filtering for AL query objects is done by either the DataItemTableFilter or filter columns property. Both of these properties are executed in the background as SQL “WHERE” clauses meaning filtering to happen after the join. This changes the outcome of queries when LeftOuterJoin is used. For example when I need a query that selects Customer Ledger Entries and corresponding detail Ledger Entries with a filter on type “Application”, when there are no applications I still want the Customer Ledger Entry information. When there are no detailed ledger entries the ON clause will give me the Customer Ledger Entry with an empty column for the detailed Ledger Entry. A WHERE clause returns 0 rows. This also applies to aggregates like SUM or COUNTThis quickly becomes a problem for more complex queries where we want to aggregate data from multiple sources that may or may have records. The workaround is to retrieve this data in separate queries but this is inefficient as some data needs to be retrieved twice.Therefore I strongly support suggestion 1 of adding a Data Item attribute that sets the filter order.Proposed parameter:DataItemJoinOrder Permitted values: “WHERE”, “ON”Default value: “WHERE”
A specific case of this is the flow event table. We want to exclude this from the audit log as it does not need to be retained for any compliance or regulatory purpose. Having the ability to do a bulk delete on this table in the audit logs would be useful. Even better would be to eliminate it from the audit log all together.