Unexpected behavior in the aggregated group using the sort function

Consider a dimension called the period and its hierarchy H_OBDOBI.This hierarchy, in addition to grand total is even as follows: year, month and week. the physical data table containing week as the finest detail. Dimension has a key called CAS_ID and is set as the time, but this is how I discovered it does not matter. Month column is VARCHAR, causing difficulty in sorting the presentation layer. You know: 1, 10, 11, 12, 2, 3, ... For this reason I set the Month column sorting key dimension on which I know is growing with time (the condition for the temporal dimension). More about alternative sorting data, see here . Thus I ensure proper sorting columns Moon. The trouble occurred elsewhere, and quite unexpectedly. If I had a column in the query show a month and aggregated indicator, the results in individual months, not grouped (the group) by week: After a bit of research I found that it causes the sorting rule. So I added another column to the physical table (PORADI_M) which I filled with the same number for each record belonging to the same month. I bypassed this problem and solved for me. To be consistent, I finally have all behavior in odladil NQQuery log. The thing is that that sort column is indeed in every case sent to the database in the group by clause.Below you can see part of the log with sql query before the change to sorting through M_PORADI: select T37. "YEAR" as c1, T37. "MONTH" and c2, sum (T55. "revenue") and c3, T37. "CAS_ID 'and c4 from "DIM_CAS $" T37, "F_PRODEJE $" T55 WHERE (T37. "CAS_ID" = T55. "CAS_ID ') group by T37. "CAS_ID" T37. "YEAR" T37. "MONTH" followed by a similar question after the change : select T37. "YEAR" as c1, T37. "MONTH" and c2, sum (T55. "take") and c3, T37. "PORADI_M" and c4 from "DIM_CAS $" T37, "F_PRODEJE $" T55 WHERE ( T37. "CAS_ID" = T55. "CAS_ID ') group by T37. "YEAR" T37. "MONTH" T37. "PORADI_M"