Name.DBalance
Generating statements involves quite a lot of database requests per statement. Statement (and invoice) forms are generated on the client, so it pays to try to eliminate unnecessary processing when statements will be generated for data that is hosted on a remote server.
Many older standard statement forms include the expression
Name.D90Plus + Name.D60Plus + Name.D30Plus + Name.DCurrent
These forms date back to before the field Name.DBalance was added (in about version 3). Normally, this calculation is harmless and cheap, unless the statement is being generated for a head office account. In that case, each of those fields is very expensive to evaluate (since it involves summing the associated field from all of the branches).
In v7.1.5, these forms have been updated to use Name.DBalance, which gets the same result, with a lot less processing in the head office case. If you have customised statements that were based on the standard statements, you are advised to make the same change.
tl;dr: Replace Name.D90Plus + Name.D60Plus + Name.D30Plus + Name.DCurrent with Name.DBalance for better statement performance for head office debtor accounts.
List Search Function
In a statement list search function, the use of the "Transaction." prefix is strongly discouraged. Just use the transaction field names.
e.g.
(Type = "DII" and TransDate <= STMT_DATE) or (Type = "DIC" and DatePaid > STMT_DATE and TransDate <= STMT_DATE) or (DatePaid > Last_Stmt) and TransDate <= STMT_DATE not (Transaction.Type = "DII" and Transaction.TransDate <= STMT_DATE) or (Transaction.Type = "DIC" and Transaction.DatePaid > STMT_DATE and Transaction.TransDate <= STMT_DATE) or (Transaction.DatePaid > Last_Stmt) and Transaction.TransDate <= STMT_DATE This is because the latter version will not be optimised by the search optimiser in v7. In fact any "." in the search expression will cause a fallback to non-optimised searching.