Total Net Revenue =
SUM ( Fact_Sales[Net_Revenue_USD] )

1. יצירהקליק ימני על Fact_Sales ← New measure
2. בדיקהגררו לקארד ריק כדי לוודא שהמספר מופיע

למה דווקא Net ולא Gross: העמודה Gross_Revenue_USD היא מחיר המחירון כפול הכמות, לפני הנחות. Net_Revenue_USD היא אותה עמודה פחות Discount_USD — כלומר מה שבאמת חויב. הפער בין השתיים בקובץ הזה הוא 7,465,587.96 USD.

תוצאה: 98,172,830.75 USD. זהו המספר הנאיבי — נחזור אליו בתרגיל 1.7.

Total Units Dispensed =
SUM ( Fact_Sales[Units_Dispensed] )

שתי עמודות, שני עולמות: Net_Revenue_USD היא כסף ו-Units_Dispensed היא כמות פיזית. שתיהן אדיטיביות לחלוטין — כל פילוח שלהן לפי כל אחד משבעת המימדים מסתכם בדיוק לסך הכל. בהמשך נגלה שהמוצר עם הכי הרבה יחידות אינו המוצר עם הכי הרבה כסף, וזה בדיוק העניין.

תוצאה: 1,096,897 יחידות.

Active Products =
DISTINCTCOUNT ( Fact_Sales[Product_ID] )

למה לא COUNT: COUNT ( Fact_Sales[Product_ID] ) היה מחזיר 28,400 — הוא סופר שורות שיש בהן ערך, לא ערכים ייחודיים. כל מוצר מופיע כאן בממוצע ב-236.7 שורות מכירה.

תוצאה: 120 מוצרים — בדיוק כל השורות ב-Dim_Product, כלומר אין מוצר בקטלוג שלא נמכר אף פעם.

Prescribers Engaged =
DISTINCTCOUNT (
    Fact_Sales[Prescriber_ID]
)

מה השאלה שהמדד עונה עליה: 1.3 שואל "כמה מוצרים זזו", ו-1.4 שואל "כמה רופאים בכלל רשמו". שני מספרים ייחודיים, שתי עמודות שונות באותה טבלת עובדות. שימו לב שהמדד הזה משתנה בכל חיתוך: בסלייסר של אזור אחד תקבלו מספר קטן בהרבה, וסכום המספרים לכל האזורים לא יהיה 300 — ספירה ייחודית אינה אדיטיבית.

תוצאה: 300 רופאים רושמים.

Revenue per Unit =
DIVIDE (
    [Total Net Revenue],
    [Total Units Dispensed]
)

עקרון הלגו: מדד חדש נבנה ממדדים קיימים, לא מעמודות. כך שינוי בהגדרת ההכנסה מתגלגל אוטומטית לכל מה שנשען עליה. DIVIDE מחזיר ריק במקום שגיאה כשהמכנה אפס — / היה מפיל את הוויזואל.

אזהרת פרשנות: זהו מחיר ליחידה משוקלל, לא ממוצע של מחירים. גנריות זולות תופסות 38.2% מהיחידות אבל רק 2.8% מהכסף, ולכן הן מושכות את המספר הזה מטה.

תוצאה: 89.5 USD ליחידה.

Oncology Revenue =
CALCULATE (
    [Total Net Revenue],
    Dim_Product[Therapeutic_Area]
        = "Oncology"
)

מה CALCULATE עושה כאן: הוא מחליף את הפילטר על Therapeutic_Area בפילטר שלו. אם הוויזואל כבר מסונן לקרדיולוגיה — המדד עדיין יחזיר אונקולוגיה. זו ההתנהגות הרגילה של CALCULATE, ובתרגיל הבא נראה איך לשנות אותה.

תוצאה: 47,694,982.99 USD — 48.58% מכלל ההכנסה. אונקולוגיה היא 18% בערך מהמוצרים אבל כמעט חצי מהכסף.

Realized Revenue =
CALCULATE (
    [Total Net Revenue],
    KEEPFILTERS (
        Fact_Sales[Order_Status] IN
            { "Dispensed", "Refilled" }
    )
)

למה KEEPFILTERS ולא CALCULATE רגיל: בלי KEEPFILTERS, אם המשתמש יבחר בסלייסר Cancelled בלבד — המדד ידרוס את הבחירה ויחזיר בכל זאת את הסכום של Dispensed ו-Refilled. המשתמש יראה מספר גדול מתחת לכותרת "מבוטל" ולא יבין. KEEPFILTERS מחתך את שני הפילטרים זה בזה במקום להחליף: בחירה של Cancelled תיתן ריק, וזו התשובה הנכונה.

הפער מול 1.1: 98,172,830.75 פחות 89,338,768.87 הם 8,834,061.88 USD של הכנסה שלא מומשה — 9.0% מהמספר הנאיבי.

תוצאה: 89,338,768.87 USD מומשו, מתוך 98,172,830.75 נאיביים.

Pct of All Products =
DIVIDE (
    [Total Net Revenue],
    CALCULATE (
        [Total Net Revenue],
        ALL ( Dim_Product )
    )
)

מה ALL עושה: הוא מסיר את כל הפילטרים מהמימד Dim_Product — לא רק מעמודת השם, אלא גם מתחום הטיפול, מהצורה ומ-Is_Generic. המכנה הופך לקבוע, והמונה ממשיך להשתנות שורה-שורה.

מבחן השפיות: בטבלה לפי Product_Name שורת ה-Total חייבת להראות בדיוק 100.00%. אם היא מראית פחות — שכחתם ALL באיזשהו מקום.

תוצאה: המוביל Endomycin = 7.36% · שורת Total = 100.00%.

Revenue vs Target =
IF (
    [Total Net Revenue] >= 750000,
    "Above Target",
    "Below Target"
)

יעד קבוע מול יעד מחושב: כאן היעד הוא מספר שכתוב בקוד. זה מכוון — יעד עסקי נקבע מראש ולא זז כשהנתונים זזים. לשם השוואה, ממוצע ההכנסה למוצר בקובץ הוא 818,106.92 USD, קרוב ליעד אבל לא זהה לו.

תוצאה: 35 מוצרים מעל היעד · 85 מתחתיו.

Product Tier =
VAR R = [Total Net Revenue]
RETURN
SWITCH (
    TRUE (),
    R >= 1500000, "Top",
    R >= 400000, "Mid",
    "Low"
)

למה VAR: בלי המשתנה, [Total Net Revenue] היה מחושב פעמיים בכל שורה. עם VAR הוא מחושב פעם אחת, והקוד גם נקרא טוב יותר.

הסדר קריטי: SWITCH עוצר בתנאי הראשון שמתקיים. אם תהפכו את שתי השורות, מוצר של 2,000,000 יקבל Mid — כי גם הוא גדול מ-400,000, והתנאי הזה נבדק ראשון.

תוצאה: 22 Top · 31 Mid · 67 Low — סך הכל 120 מוצרים.

Tier Color =
SWITCH (
    [Product Tier],
    "Top", "#132449",
    "Mid", "#F5C518",
    "Low", "#A9B4CC"
)

שני פרצופים של SWITCH: ב-1.10 הארגומנט הראשון היה TRUE () וכל זוג הוא תנאי ותוצאה. כאן הארגומנט הראשון הוא ביטוי, וכל זוג הוא ערך ותוצאה. אותה פונקציה, שתי צורות שימוש.

שימו לב: המדד הזה לא מוצג למשתמש לעולם. הוא קיים כדי להזין עיצוב מותנה — נשתמש בו בתרגיל 3.2.

שלושת הערכים: #132449 · #F5C518 · #A9B4CC.

Product Rank =
RANK (
    DENSE,
    ALLSELECTED (
        Dim_Product[Product_Name]
    ),
    ORDERBY (
        [Total Net Revenue], DESC
    )
)

DENSE מול SKIP: אם שני מוצרים חולקים מקום 3, DENSE ייתן לבא אחריהם 4, ו-SKIP ייתן לו 5. בדירוג הצגה למשתמש DENSE כמעט תמיד מה שרוצים.

למה ALLSELECTED ולא ALL: ALLSELECTED מכבד סלייסרים. אם המשתמש סינן לאונקולוגיה, הדירוג ייבנה מחדש בתוך הקבוצה הזו ויתחיל מ-1 — וזה מה שמשתמש מצפה לראות. עם ALL הדירוג היה נשאר גלובלי והטבלה הייתה מתחילה ממקום 7 או 12.

תוצאה: Endomycin = 1 · Branpril = 120 (המקום האחרון מבין 120).

Leader Revenue =
CALCULATE (
    [Total Net Revenue],
    INDEX (
        1,
        ALLSELECTED (
            Dim_Product[Product_Name]
        ),
        ORDERBY (
            [Total Net Revenue], DESC
        )
    )
)

מה INDEX מחזיר: שורה אחת מתוך רשימה ממוינת. 1 = הראשונה, -1 = האחרונה. כאן המיון יורד לפי הכנסה, ולכן השורה הראשונה היא המובילה.

למה זה שימושי: ברגע שיש לכם את ערך המוביל בכל שורה, אפשר לכתוב פער באחוזים מהמוביל בשורה אחת: DIVIDE ( [Total Net Revenue], [Leader Revenue] ).

תוצאה: 7,230,122.08 USD בכל שורה — ההכנסה של Endomycin.

Rolling 3M Revenue =
AVERAGEX (
    WINDOW (
        -2, REL, 0, REL,
        ALLSELECTED (
            Dim_Date[Month_Key],
            Dim_Date[Month_Year]
        ),
        ORDERBY (
            Dim_Date[Month_Key], ASC
        )
    ),
    [Total Net Revenue]
)

לקרוא את הארגומנטים: -2, REL = שתי שורות אחורה יחסית לשורה הנוכחית · 0, REL = עד השורה הנוכחית עצמה. יחד: חלון של שלוש שורות. AVERAGEX מריץ את המדד על כל אחת מהן ומחזיר ממוצע.

למה ממיינים לפי Month_Key ולא לפי Month_Year: Month_Year הוא טקסט — Apr-2025 יבוא לפני Jan-2026 באלפבית ויהרוס את החלון. Month_Key הוא מספר שלם בפורמט YYYYMM, ולכן המיון שלו כרונולוגי. שתי העמודות חייבות להיות בטבלה שהחלון בנוי עליה.

שתי השורות הראשונות: אין להן שלושה חודשים אחורה, ולכן הן מחזירות ממוצע של שורה אחת ושתיים בהתאמה. זו התנהגות נכונה, לא באג.

תוצאה: Mar-2024 = 3,870,749.35 · Jun-2026 = 2,876,205.93 — על פני 30 חודשים.

התשובה. המספר 98,172,830.75 סוכם את Net_Revenue_USD על כל 28,400 השורות — כולל 1,730 שורות Cancelled ו- 784 שורות Reversed. שורות כאלה נרשמו במערכת התפעולית עם סכום מלא, כי הסכום נקבע ברגע ההזמנה ולא ברגע האספקה. הן נושאות 8,834,061.88 USD שמעולם לא נכנסו לקופה.

למה זה לא נראה שגוי בוויזואל. העמודה אדיטיבית לחלוטין: כל פילוח שלה — לפי ערוץ, לפי אזור, לפי חודש — מסתכם בדיוק לאותו סך הכל. שום בדיקת עקביות לא תצעק. הטעות אינה חשבונית אלא הגדרתית: העמודה עונה על השאלה "כמה כסף נרשם", והמשתמש קרא אותה כאילו היא עונה על "כמה כסף נכנס".

הפער אינו אחיד, וזה החלק המסוכן. אילו הביטולים היו מתפזרים שווה בשווה, המספר הנאיבי היה מנופח באותם 9.0% בכל מקום והדירוגים היו נשארים נכונים. בפועל הם לא מתפזרים שווה: המוביל Endomycin יורד מ-7,230,122.08 ל- 6,671,042.61 כשמסננים לסטטוס שמומש, ואילו Renanavir יורד מ-6,893,688.31 ל-6,261,554.95 — ירידה קטנה יותר באחוזים. כל דירוג, כל אחוז וכל "מי המוביל" נבנים מחדש.

מה עושים בפועל. שלוש אפשרויות, לפי סדר העדפה: (1) מדד Realized Revenue עם KEEPFILTERS כפי שכתבנו ב-1.7, ומשאירים גם את המספר הנאיבי בדשבורד בשם מפורש כמו Booked Revenue; (2) פילטר ברמת הדוח על Order_Status — פשוט, אבל מסתיר את המידע על הביטולים לגמרי; (3) סינון ב-Power Query — מהיר יותר, אבל השורות נמחקות מהמודל ואי אפשר יותר לנתח את הביטולים עצמם. אל תבחרו ב-(3) לפני שווידאתם שאף אחד לא צריך לספור ביטולים.

הפער: 8,834,061.88 USD — 9.0% מהמספר הנאיבי.

Page background
  Color = #0C1114
  Transparency = 0%

Shape: Rectangle (title bar)
  Position X 0  Y 0
  Width 1280  Height 76
  Fill #132449

Shape: Rectangle (KPI tray)
  Position X 24  Y 96
  Width 1232  Height 150
  Fill #FFFFFF  Transparency 92%
  Rounded corners 12
  Border on, color #FFFFFF 88%

למה מגש ולא ארבעה רקעים: ארבעה קארדים על רקע אחד נקראים כקבוצה. ארבעה מלבנים נפרדים נקראים כארבעה דברים לא קשורים. זה ההבדל היחיד, והוא גדול.

סדר שכבות: ב-Format ← Selection pane ודאו שהמגש נמצא מתחת לקארדים. אם הוא מעליהם הם ייעלמו והתסכול יהיה גדול.

קנבס בגודל 1280x720, פס כותרת בגובה 76 ומגש אחד בגובה 150 — ריק לעת עתה.

Insert ribbon -> Image
  Scaling = Fit  (never Fill)
  Lock aspect ratio = On
  Position X 24  Y 18
  Height 40

Title text box
  Font Segoe UI Semibold 22
  Color #F5C518
  Vertical align = Middle

Fit מול Fill: Fill ממלא את המסגרת וחותך את מה שחורג — לוגו מרובע במסגרת רחבה יאבד את הצדדים. Fit משאיר את הפרופורציות ומוסיף שוליים. ללוגו תמיד Fit.

נגישות: לכל תמונה שאינה דקורטיבית הוסיפו General ← Alt text. קורא מסך יקריא אותו.

לוגו ואייקון בגובה 40 בפס הכותרת, יחס מקורי נשמר, לשניהם Alt text.

Card 1  [Total Net Revenue]
  Callout value: 28pt, #FFFFFF
  Display units = Millions
  Value decimal places = 2
  Category label = On

Card 2  [Realized Revenue]
  Callout color #F5C518

Card 3  [Total Units Dispensed]
Card 4  [Active Products]

Align: Format -> Align ->
       Distribute horizontally

למה שני קארדי הכנסה זה לצד זה: זו כל הפואנטה של החבילה. המשתמש רואה 98,172,830.75 ולידו 89,338,768.87 ושואל מיד למה יש הבדל — וזו בדיוק השאלה שרצינו שישאל. קארד בודד היה מסתיר אותה.

Display units: ב-Millions הקארד יראה 98.17M. זה קריא, אבל ודאו שהמשתמש מבין את היחידה — הוסיפו אותה לכותרת הקארד ולא רק לערך.

ארבעה קארדים: 98,172,830.75 · 89,338,768.87 · 1,096,897 · 120.

Clustered bar chart
  Y axis: Therapeutic_Area
  X axis: [Total Net Revenue]
  Sort by X axis, Descending
  Data labels = On
  Display units = Millions
  Y axis title = Off
  Gridlines = Off

למה אופקי ולא אנכי: שמות התחומים ארוכים (Infectious Disease). בגרף אנכי הם היו מסתובבים באלכסון או נחתכים. בגרף אופקי הם נקראים ישר.

שמונה עמודות. המובילה: Oncology עם 47,694,982.99 (48.58%).

Line chart
  X axis: Dim_Date[Month_Year]
  Sort by Dim_Date[Month_Key] ASC
  Y axis: [Total Net Revenue]
         [Rolling 3M Revenue]

Lines -> Total Net Revenue
  Stroke width 2, Smooth = Off

Lines -> Rolling 3M Revenue
  Stroke width 3, Smooth = On
  Color #F5C518

המיון הוא הכל. אם לא תמיינו לפי Month_Key, הציר יסודר אלפביתית ותקבלו קו זיגזג חסר משמעות. Sort by column על Month_Year בטבלת התאריכים פותר את זה לתמיד.

מוחלק על מי: את הקו הגולמי משאירים חד — הוא הנתון. את קו הממוצע הנע מחליקים — הוא ההסבר. להחליק את שניהם זה להסתיר את הרעש שבגללו הוספתם את הממוצע מלכתחילה.

30 נקודות. שיא: Jan-2025 עם 4,280,304.53 USD. שתי הנקודות הראשונות של הממוצע הנע חלקיות.

New page -> rename to Detail

Slicer: Dim_Channel[Channel_Name]
  Style = Tile
  Selection = Multi-select
  Show Select all = On

View ribbon -> Sync slicers
  Page Overview
    Sync = On   Visible = On
  Page Detail
    Sync = On   Visible = Off

Sync מול Visible: שתי תיבות סימון נפרדות. Sync אומרת "הבחירה מתגלגלת לעמוד הזה". Visible אומרת "הסלייסר מצויר בעמוד הזה". סימון Sync בלבד הוא בדיוק מה שרוצים כאן: הסינון עובר, הפקד לא תופס מקום פעמיים.

מלכודת נפוצה: אם תשכפלו עמוד (Duplicate page) הסלייסר המשוכפל לא יסונכרן אוטומטית. בדקו את הטבלה ב-Sync slicers אחרי כל שכפול.

שני עמודים, סלייסר אחד גלוי בלבד, חמישה ערכי ערוץ, בחירה מרובה פעילה.

Table visual
  Columns:
    Dim_Product[Product_Name]
    [Total Net Revenue]
    [Realized Revenue]
    [Pct of All Products]
    [Product Rank]
    [Product Tier]

  Totals = On
  Sort by [Total Net Revenue] DESC
  Column headers: wrap text On
  Values font size 11

מה שורת ה-Total חייבת להראות: Pct of All Products = 100.00% בדיוק. Product Rank יראה שם ריק או 1 — זו התנהגות תקינה של פונקציית חלון בהקשר הכולל, לא באג. אם רוצים לנקות אותה, עטפו את המדד ב-IF ( HASONEVALUE ( ... ), ... ).

הפער שהטבלה חושפת: ההפרש בין שתי עמודות ההכנסה אינו קבוע באחוזים בין השורות. זו התצוגה הכי ישירה של המלכודת מתרגיל 1.15.

120 שורות. Total = 98,172,830.75 · 89,338,768.87 · 100.00%.

Filters pane -> Product_Name
  Filter type = Top N
  Show items = Top 10
  By value = [Total Net Revenue]
  Apply filter

Visual: Clustered bar chart
  Sort by [Total Net Revenue] DESC
  Data labels On, Millions, 2 dp

למה לא לרשום עשרה שמות ביד: פילטר Top N מחושב מחדש בכל חיתוך. אם המשתמש יבחר בסלייסר את Mail Order, הרשימה תתעדכן לעשרת המובילים בערוץ הזה. רשימת שמות קבועה תישאר תקועה על המובילים הגלובליים ותציג נתונים לא רלוונטיים.

בדיקה שכדאי להריץ: החליפו את By value ל-[Total Units Dispensed] ותקבלו רשימה כמעט אחרת לגמרי — Oncozumab מוביל בכמות עם 30,681 יחידות, ואינו נמצא בעשירייה של הכסף בכלל.

עשר עמודות. מקום 1: Endomycin · מקום 10: Endoparib.

Matrix
  Rows:    Therapeutic_Area
  Columns: Channel_Group
  Values:  [Total Net Revenue]

  Row subtotals = On
  Column subtotals = On
  Layout = Tabular
  Stepped layout = Off
  Display units = Millions

מבחן האדיטיביות: סכום כל התאים בגוף המטריצה חייב להיות בדיוק 98,172,830.75. זה עובד כי Total Net Revenue הוא SUM טהור. נסו להחליף אותו ב-Prescribers Engaged — הסיכומים לא יסתכמו, כי ספירה ייחודית אינה אדיטיבית. אותו רופא נספר פעם אחת בשורה שלו ופעם אחת בסיכום.

שלוש קבוצות ערוץ בלבד: Direct To Patient (Retail Counter + Mail Order), Institutional (Hospital Supply + Specialty Clinic) ו-Trade (Wholesale Direct). מטריצה של 8x3 נקראית; 8x5 כבר צפופה מדי למסך.

8 שורות על 3 עמודות. התא הגדול: Oncology x Direct To Patient = 26,939,415 USD. סך הכל = 98,172,830.75.

Line and clustered column chart
  X axis: Dim_Date[Quarter_Name]
  Column y-axis: [Total Net Revenue]
  Line y-axis:   [Revenue per Unit]

  Secondary axis = On
  Line stroke 3, color #F5C518
  Column data labels = On
  Line data labels = Off

מתי מותר ציר משני: רק כששתי הסדרות מודדות דברים שונים ביחידות שונות — כאן דולרים מול דולר-ליחידה. שתי סדרות באותה יחידה על שני צירים זו הטעיה: המשתמש רואה שני קווים נחתכים שלא באמת נחתכים.

מה הגרף הזה מגלה: ההכנסה עונתית — Q1 חזק בשתי השנים (11,612,248 ו-10,858,103), Q3 חלש. אבל המחיר ליחידה כמעט לא זז, ולכן העונתיות היא כמות ולא תמחור. זו מסקנה שאף אחת משתי הסדרות לבדה לא נותנת.

10 רבעונים. הגבוה: 2024-Q1 = 11,612,248.05 USD.

Insert -> Buttons -> Navigator
     -> Page navigator
  Position: title bar, X 980 Y 20

Each visual
  Title = On, 12pt, #A9B4CC
  Background = Off
  Border = Off

Format -> Align -> Align left/top
  Distribute vertically

Selection pane -> Tab order
  1 title  2 KPI tray  3 cards
  4 bar  5 line  6 table

למה Page navigator ולא כפתורים ידניים: הוא מוסיף אוטומטית כפתור לכל עמוד גלוי, מסמן את העמוד הנוכחי, ומתעדכן לבד כשמוסיפים עמוד. כפתורים ידניים דורשים Action ← Page navigation לכל אחד ונשברים בשינוי שמות.

הבדיקה האחרונה לפני מסירה: לחצו Ctrl + Shift + F, עברו על כל הוויזואלים ב-Tab בלבד וודאו שהסדר הגיוני. ויזואל דקורטיבי — מלבן, קו מפריד — סמנו Hide ב-Tab order כדי שלא ייתפס במקלדת.

שני עמודים מלוטשים, Page navigator בשניהם, Tab order מוגדר, אפס ויזואלים חופפים.

Format visual -> Cell elements
  Series: Total Net Revenue
  Background color = On -> fx
  Format style = Rules
  Based on = [Total Net Revenue]

  If value >= 1500000 and <= MAX
     then #132449
  If value >= 400000 and < 1500000
     then #F5C518
  If value >= MIN and < 400000
     then #A9B4CC

מה לשים לב: החוקים נבדקים לפי הסדר, ולכן הגבולות חייבים להיות רציפים ולא חופפים. שימו לב גם ש-Power BI מבדיל בין is greater than ל-is greater than or equal to — מוצר של בדיוק 400,000 חייב לקבל Mid, ולכן >=.

החיסרון: שלושת החוקים חיים בתוך הוויזואל הזה בלבד. שינוי סף מחייב לחזור לכל ויזואל בנפרד — וזה בדיוק מה שנתקן בתרגיל הבא.

החלוקה: 22 כהה · 31 צהוב · 67 אפור.

Format visual -> Cell elements
  Series: Product Tier
  Background color = On -> fx
  Format style = Field value
  What field should we base
  this on? = [Tier Color]

  Font color = On -> fx
  Format style = Field value
  Field = [Tier Text Color]

למה זה חזק יותר: Tier Color הוא מקור אמת יחיד. שינוי אחד בקוד ה-SWITCH מתגלגל לכל ויזואל שמשתמש בו — טבלה, Matrix, גרף וקארד. החוקים של 3.1 חיים בוויזואל אחד בלבד.

אם הטקסט לא נקרא על הרקע הכהה #132449 — כתבו מדד קצר נוסף והזינו אותו ל-Font color באותה דרך:

Tier Text Color =
SWITCH (
    [Product Tier],
    "Top", "#FFFFFF",
    "#111111"
)

שתי הטכניקות מייצרות בדיוק את אותה חלוקה: 22 / 31 / 67.

1. הערוץ הגדול אינו הרווחי ביותר. Retail Counter מביא 40.68% מההכנסה — יותר מכל ערוץ אחר — אבל אחוז המרווח שלו 73.91%, נמוך מזה של Specialty Clinic שעומד על 75.5%. כל שקל שעובר במרפאת המומחים מייצר יותר רווח משקל שעובר בדלפק.

2. הזנב הוא הבעיה, לא הראש. Wholesale Direct הוא הקטן שבערוצים (8.47% מההכנסה) וגם הפחות רווחי (70.48%). מכפלת שני החולשות היא מה שהופך אותו למועמד הראשון לבדיקה — לא הגודל שלו לבדו ולא האחוז שלו לבדו.

3. מאיפה הפער מגיע. ההסבר אינו בערוץ אלא בתמהיל שעובר בו. Specialty Clinic נושא את התרופות היקרות בעלות המרווח הגבוה — אונקולוגיה ואימונולוגיה. Wholesale Direct נושא נפח גדול של גנריות זולות, שבהן העלות היא 58% עד 78% מהמחיר. הערוץ אינו "פחות יעיל"; הוא פשוט מוכר מוצרים אחרים. זו ההבחנה שמפרידה בין מסקנה נכונה לבין החלטה יקרה.

4. מה זה אומר על החלטה. "לסגור את Wholesale Direct" היא המסקנה הפזיזה. הערוץ מייצר 5,863,920.93 USD מרווח גולמי בפועל, ורוב העלויות שלו משתנות ולא קבועות. השאלה הנכונה היא אם אפשר להזיז אליו תמהיל מוצרים אחר — לא אם למחוק אותו.

5. איך בודקים את זה בעצמכם. בנו Matrix עם Channel_Name בשורות ו-Is_Generic בעמודות, וערך DIVIDE ( SUM ( Fact_Sales[Gross_Margin_USD] ), [Total Net Revenue] ). הפער בין העמודות יהיה גדול בהרבה מהפער בין השורות — וזו ההוכחה שהתמהיל, ולא הערוץ, הוא שמסביר את הרווחיות.

ואזהרה אחרונה: כל המספרים בטבלה הזאת חושבו על ההכנסה הנאיבית. הריצו אותם שוב עם Realized Revenue לפני שאתם מציגים אותם למישהו — סדר הערוצים לפי אחוז מרווח עשוי להשתנות, וזו בדיוק הסיבה שכתבנו את המדד ההוא.

הרווחי ביותר באחוז מרווח: Specialty Clinic (75.5%) · הפחות רווחי: Wholesale Direct (70.48%).

כל התוצאות אומתו ב-pandas מול Pharma_PowerBI_Star.xlsx (28,400 שורות עובדה), וכל שבעת הקשרים נבדקו תכנותית — 0 מפתחות יתומים, 0 תאים ריקים, 0 תלויות מעגליות ו-0 נתיבי סינון כפולים.