А можно ближе к теме: какие измерения и меры существуют в кубе?

Отчетная форма - это результат выполнения запроса. Чтобы помочь Вам правильно составить запрос, мне нужно понимать, к чему его адресовать. Поскольку структуру куба Вы привести не хотите, мне остается импровизировать. У Вас, очевидно, есть справочник товара с полями Товар и Срок хранения. У Вас также должна быть таблица фактов, отслеживающая приход / расход товара вида (ID, Дата, Товар, Движение, Дата_Прихода). Поле Дата_Прихода уточняет, за какую именно дату товар расходуется. Т.е. понятно, что если у нас до этого один и тот же товар поступал вчера и позавчера, то при его расходе мы должны оговорить, который из них конкретно сегодня расходуется. Т.о. Дата_Прихода = Дата, если Движение > 0, и Дата <=, если Движение < 0. Т.е. Дата_Прихода выступает в нашем случае атрибутом товара - коль скоро товары устаревают, лежа на складе, нужно их различать не т.по наименованию, но и по дате поступления. Тогда измерение Товар получает еще один нижележащий уровень - Дата_Прихода. Срок_хранения кладем как member property уровня Товар.

Вот запрос, к-й дает то, что нужно

with member Measures.Expired as 'sum(filter(Product.CurrentMember.Children, datediff("d", cdate(Product.CurrentMember.Name), cdate(Time.CurrentMember.Name)) > cint(Product.CurrentMember.Parent.Properties("Expiration"))), Measures.[NarIt])'
select Descendants(Product, ID) on rows, crossjoin({Measures.Expired}, Descendants(Time, Day)) on columns
from Activity

Пояснения.
Measures.NarInt - это calculated member, к-й считает Приход / Расход нарастающим итогом по времени. Ввиду элементарности здесь не расшифровывается.
Измерение Product состоит из 2-х уровней - ID (товара) и Дата Прихода. Уровень ID имеет custom property Expiration - срок годности данного товара.
Сalculated member Measures.Expired суммирует для данной даты нарастающий итог прихода / расхода для всех товаров разного времени поступления внутри данного наименования у к-х разница между текущей датой и сроком поступления превышает срок хранения. Это и будет Ваш Остаток Просроченный.

Идея, надеюсь, ясна. Возможно, структуру куба и сам запрос можно выстроить более оптимально, но это уже отдельное время (которое, как известно, деньги )

Это неправильно. Срок хранения должен быть атрибутом товара и учитываться в операционном источнике по издоженным выше соображениям. В противном случае можно, конечно, сделать member property Срок Хранения, привязав его к какой-нибудь fake column в товаре, сделать Товар write-enabled измерением и обновлять member property из клиента. Но это неэлегантно.