Продажа, оформленная в сентябре и отгруженная в октябре, относится к разным месяцам в двух операционных отчётах. В Power BI это определяется ролью календарной связи, а не только названием показателя. Руководство Microsoft проверено 14 октября 2026 года.

Опишите события до настройки модели

В учебной таблице один заказ создан 30 сентября, отгружен 2 октября. Второй создан 3 октября и пока не отгружен. Октябрь по дате создания содержит второй заказ; октябрь по дате отгрузки — первый. Оба отчёта корректны при ясной подписи.

Не заполняйте неизвестную дату отгрузки датой заказа ради красивого календаря. Это превратит незавершённое событие в якобы состоявшееся. Если одна строка исходной таблицы обозначает товарную позицию, заранее уточните способ подсчёта заказов: количество строк может не совпадать с количеством покупок.

Когда достаточно неактивной связи

По документации активная связь распространяет фильтры по умолчанию. Неактивная используется, когда её включает соответствующее выражение DAX. Для модели с основным анализом по дате заказа и отдельной мерой отгрузок Microsoft показывает USERELATIONSHIP внутри CALCULATE.

В такой схеме календарь связан активно с датой создания, а мера отгрузок использует связь с датой отправки. Назовите меры соответственно: «Заказы по дате создания» и «Отгрузки по дате отправки». Одинаковая подпись «Количество» скрывает различие даже при технически верной формуле.

Когда нужны две роли календаря

Если нужно одновременно отобрать заказы сентября и отгрузки октября, один переключаемый путь не заменяет два независимых фильтра. Руководство рекомендует отдельные экземпляры измерения для разных ролей, когда требуется одновременный анализ. Их поля должны ясно обозначать событие.

Проверьте влияние каждого фильтра на учебную пару заказов. После выбора сентября по созданию и октября по отгрузке должен остаться первый. Второй не должен попасть в отправленные только потому, что дата создания находится в октябре. Это редакционный сценарий приёмки, который переносится на реальные данные после согласования их структуры.

Проверьте доступ и незавершённые события

Microsoft отдельно указывает, что фильтры RLS распространяются только по активным связям; USERELATIONSHIP не превращает неактивный путь в путь распространения RLS. Если модель ограничивает доступ по строкам, её проверка обязательна в соответствующей роли пользователя.

Сохраните отдельный контроль заказов без отгрузки и проверьте общий итог с исходником. Основа построения описана в материале о модели Power BI. Спорные записи удобно разбирать через страницу детализации. Результат должен объяснять различие месяцев конкретными событиями, а не искусственно выравнивать два показателя до одинакового числа.