I wonder, where it would really help me.
The usual business logic (as total = amount * single_price or gross_price = net_price * (1 + tax_rate)) does not really be needed to parametrizised. Of course there should be a table for the tax rate based on order time and maybe state and maybe product_category etc., but this is a whole other ticket and can / should be done with JOINing the tax_rate-table.
In my previous job we had a similar system for the user interface, which had a ton of shown lists that could be sorted / filtered / limited by the user in almost any combination. So we had the a base script for e.g. the order table:
FROM dbo.orders AS o
INNER JOIN dbo.customers AS c
ON c.customer_id = o.customer_id
WHERE 1 = 1
AND c.last_name LIKE @last_name
AND c.country LIKE @country
AND o.order_date >= @order_date_from
AND o.order_date <= @order_date_to
This scripts was stored in a text file (for source control), but could have been in a SQL table too.
When the user opened the order overview, the mid tier application service took this script (was read once at the service start for perfomance reasons and stored in memory). When the user had applied a filter e.g. in the order_from filter, the application service put this filter in the parameter list for the script, OTHERWISE it removed the whole line for this parameter (the filter field's name was equal to the parameter name). So if no filter was set, there was just a WHERE 1 = 1 given to the SQL server for execution, with only a filter on the last_name, all lines which included an @ (or any other char you defined) except the line with @last_name were removed.
God is real, unless declared integer.