Comments
Only other way around this is to hope there is a column of numeric values and the data set isn't very large. You can then use "View Column Totals" and set it to whatever value you prefer. When you click "calculate" in the bottom left, it will generate the total number of rows, adjust based on rows selected or not, and also adjust the column totals based on selection.However, this way is just a workaround. If the page is very large, it will still commandeer your screen as it calculates the totals.
This is more than a convenience issue—being able to use a standard windowed envelope is a basic necessity to ensure accuracy, ease of processing, and correct delivery to the intended recipient. Ironically, the move away from using pre‑printed forms, while well‑intended, has made mailing more difficult rather than easier due to the current layout. This creates unnecessary manual steps and increases the risk of errors when sending required tax documents.
This doesn't solve your request for the 1099 Vendor Information report, but I just suggested to a customer that the use the Vendor Ledger Entries page in Analysis Mode, allowing them to summarize by vendor and view the invoiced amount vs. IRS 1099 reporting amount. That also allows them to include the Form Box column or add a row group for the box.
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”