Not sure exactly what you are asking. But I assume the following in my answer:
- data entry for user on account Parameter (from the context, I think it is a price)
- data entry for user on level0 Period, i.e. the months
- you want Essbase to show the Parameter value as typed in at the month level (Jan .. Dec)
- you want Essbase to show Costs / Quantity for Q1/2/3/4 and the YearTotal
- the Account and Period dimension are of density: dense
You did not specify if you are also reporting on YTD values and how you have implemented this in Essbase. I assume you do, but the preferred solution depends on how you have implemented this, so I take the "safe" solution here:
solution 1
This is the most straightforward solution:
- Implement a "parameter_inp" account on which the user keys in the data. Set the account to "never consolidate".
- Create a new "parameter" account, dynamic calc, and give it the formula "Costs/Quantity;".
- Refer to "parameter" in your reports, and to "parameter_inp" for user entry
solution 2 - alternative
If you have a lot of these parameters, you'll end up with a system making it unpleasant for data entry and reporting for the end-users. To solve it using data entry and reporting on the same "parameter" account, you need to tune your implementation for Quarter and YearTotal calculation, including the YTD calculation. I see no way of getting this correct if you are using DTS.
This is the way to go forward:
- Make use of a new dimension called "View", data entry on PER (= periodic), additional dynamic calc member "YTD", density: dense, place it after Period (so Account, Period, View)
- Add a UDA to the "parameter", for example "WA"
- Set custom dynamic calculations on Quarter and YearTotal level, something like: IF (@ISUDA("WA")) THEN ELSIF <check on FLOW/BALANCE> ... logic for regular aggregation of FLOW and BALANCE items hereby overriding Essbase's native time logic)
- Set custom dynamic calculations for YTD (overiding DTS), and make an exception for UDA "WA"