מינוי עם תוספים

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

שיקולים

כדאי לקחת בחשבון את הנקודות הבאות כשמשתמשים בתכונה 'מינוי עם חבילות ערוצים':

  • מינוי עם חבילות ערוצים נתמך רק במינויים בסיסיים שמתחדשים אוטומטית.

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

  • אפשר להוסיף עד 50 פריטים למנוי עם רכישת חבילות.

  • התכונה הזו לא זמינה בקוריאה הדרומית (KR).

שילוב עם ספריית החיובים ב-Play

בקטע הזה מוסבר איך לשלב את התכונה 'מינוי עם חבילות' עם ספריית החיובים ב-Play‏ (PBL). המדריך הזה מניח שאתם מכירים את השלבים הראשונים בשילוב של PBL, כמו הוספת התלות של PBL לאפליקציה, הפעלה של BillingClient והתחברות ל-Google Play. בקטע הזה נתמקד בהיבטים של שילוב PBL שספציפיים למינוי עם חבילות ערוצים.

הפעלת תהליך רכישה

כדי להפעיל תהליך רכישה של מינוי עם חבילות ערוצים, מבצעים את השלבים הבאים:

  1. אפשר לאחזר את כל פריטי המינוי באמצעות השיטה BillingClient.queryProductDetailsAsync.

  2. מגדירים את האובייקט ProductDetailsParams לכל פריט.

    הפריט שמיוצג על ידי אובייקט ProductDetailsParams, מציין גם את ProductDetails שמציין את פריט המינוי, וגם את offerToken שבוחר מינוי ספציפי base plan או offer.

  3. מציינים את נתוני הפריט בשיטה BillingFlowParams.Builder.setProductDetailsParamsList. בקטע BillingFlowParams מפורטים השלבים בתהליך הרכישה.

    הדוגמה הבאה מראה איך להפעיל את רצף פעולות החיוב לרכישת מינוי עם כמה פריטים:

    Java

       BillingClient billingClient = ;
    
        // ProductDetails obtained from queryProductDetailsAsync().
        ProductDetailsParams productDetails1 = ...;
        ProductDetailsParams productDetails2 = ...;
        ArrayList productDetailsList = new ArrayList<>();
        productDetailsList.add(productDetails1);
        productDetailsList.add(productDetails2);
    
        BillingFlowParams billingFlowParams =
            BillingFlowParams.newBuilder()
               .setProductDetailsParamsList(productDetailsList)
               .build();
        billingClient.launchBillingFlow(billingFlowParams);

הכללים שחלים על פריטים ברכישה

  • כדי לוודא שתאריכי החידוש של התוספים יתאימו בסופו של דבר למוצר הבסיסי, יכול להיות ש-Google Play תוסיף חיוב יחסי אחרי תקופת ניסיון או תקופת מחיר היכרות.
  • הזכאות למבצע תיבדק בנפרד לכל פריט.

עיבוד רכישות

תהליך העיבוד של מינוי עם חבילות זהה לתהליך העיבוד של רכישת מינוי יחיד, כפי שמתואר במאמר שילוב של ספריית החיובים ב-Google Play באפליקציה. ההבדל היחיד הוא שהמשתמש יכול לקבל כמה הרשאות ברכישה אחת. רכישה של מינוי עם חבילות מחזירה כמה פריטים שאפשר לאחזר באמצעות Purchase.getProducts() בספריית החיובים ב-Google Play, ואז את הרשימה lineItems ב-purchases.subscriptionsv2.get של ממשק API של Google Play למפתחים.

שינוי מינויים עם חבילות

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

כדי לשנות או לשחזר רכישה קיימת של מינוי עם חבילות בערוץ באפליקציה, צריך לקרוא ל-API‏ launchBillingFlow עם פרמטרים נוספים, ולוודא את הדברים הבאים:

  • תמיד מתקשרים אל setOldPurchaseToken עם אסימון הרכישה של רכישת המינוי הנוכחית.
  • כדי לשדרג, לשנמך או לשנות את סוג המינוי של פריט, צריך להתקשר למספר SubscriptionProductReplacementParams.setReplacementMode ולציין איך המערכת צריכה לטפל בשינוי המינוי בין פריט הרכישה הישן לחדש. אחרת, אין צורך להגדיר את המאפיין SubscriptionProductReplacementParams.
  • אם פריט הבסיס לא משתנה, עדיין אפשר לקרוא ל-SubscriptionProductReplacementParams.setSubscriptionReplacementMode כדי להחיל התנהגות החלפה ספציפית. לכללים הרלוונטיים במקרה הזה, אפשר לעיין במאמר חידוש המינוי או מעבר לתוכנית אחרת באותו מינוי.
  • התוספים החדשים יחולו באופן מיידי עם חיוב יחסי כדי לאחד בין תאריך החידוש הבא לבין פריט הבסיס במינוי.
  • התוספים שהוסרו יפוגו בסוף תקופות החיוב הנוכחיות שלהם.
  • כשמפעילים את רצף פעולות החיוב, צריך לציין את כל הפריטים הפעילים במינוי עם תוספים, למעט הפריטים שרוצים להסיר, וגם את כל התוספים החדשים.

בדוגמה הבאה אפשר לראות איך קוראים ל-API‏ launchBillingFlow כשמשנים רכישה קיימת של מינוי עם חבילות:

Java

BillingClient billingClient = ;

int replacementMode =;

// ProductDetails obtained from queryProductDetailsAsync().
ProductDetailsParams productDetails1 = ...;
ProductDetailsParams productDetails2 = ...;
ProductDetailsParams productDetails3 = ...;

ArrayList newProductDetailsList = new ArrayList<>();
newProductDetailsList.add(productDetails1);
newProductDetailsList.add(productDetails1);
newProductDetailsList.add(productDetails1);

BillingFlowParams billingFlowParams =
    BillingFlowParams.newBuilder()
        .setSubscriptionUpdateParams(
          SubscriptionUpdateParams.newBuilder()
              .setOldPurchaseToken(purchaseTokenOfExistingSubscription)
              // No need to set if change does not affect the base item.
             .setSubscriptionReplacementMode(replacementMode)
             .build())
        .setProductDetailsParamsList(productDetailsList)
        .build();

billingClient.launchBillingFlow(billingFlowParams);

תרחישים של שינוי מינוי

בטבלה הבאה מפורטים תרחישים שונים של שינויים במינוי עם חבילות, וההתנהגות שמתאימה לכל תרחיש.

כשמשתמשים ב-SubscriptionProductReplacementParams

פריטים קיימים פריטים ששונו האם צריך להגדיר את מצב ההחלפה ב-SubscriptionProductReplacementParams? התנהגות
‫A (פריט בסיסי), B ‫A (פריט בסיסי) כן (שימוש ב-KEEP_EXISTING)
  • פריט ב' מתוזמן להסרה מושהית.
  • פריט א' נשמר.
  • המשתמשים ימשיכו לשלם את המחיר הנוכחי של פריט א', כולל כל יתרה של תשלומים במחיר מבצע שהם קיבלו בזמן ההרשמה.
A ‫A (פריט בסיסי), B כן (משתמשים ב-KEEP_EXISTING עבור A)
  • פריט ב' נוסף באופן מיידי עם חיוב יחסי.
  • פריט א' נשמר.
  • המשתמשים ימשיכו לשלם את המחיר הנוכחי של פריט א', כולל כל יתרה של תשלומים במחיר מבצע שהם קיבלו בזמן ההרשמה.
‫A (פריט בסיס), B א' (פריט בסיסי), ג' כן (משתמשים ב-KEEP_EXISTING עבור A)
  • הסרת B נדחית.
  • המשתמש C יתווסף מיד עם חיוב יחסי.
  • פריט א' נשמר.
  • המשתמשים ימשיכו לשלם את המחיר הנוכחי של פריט א', כולל כל יתרה של תשלומים במחיר מבצע שהם קיבלו בזמן ההרשמה.
‫A (פריט בסיסי), B B (פריט בסיסי) לא מתוזמנת הסרה מושהית של A.
‫A (פריט בסיסי), B C (פריט בסיסי) כן
  • התחליף ל-A -> C תלוי ב-SubscriptionProductReplacementParams replacementMode
  • הסרת B נדחית.
‫A (פריט בסיס), B C (פריט בסיסי), B כן
  • ההחלפה של A -> C תלויה ב-SubscriptionProductReplacementParams replacementMode.
  • כדי להשאיר את פריט B ללא שינוי, מגדירים את מצב ההחלפה שלו כ-KEEP_EXISTING.
‫A (פריט בסיסי), B C (פריט בסיס), D כן
  • ההחלפה של A -> C תלויה ב-SubscriptionProductReplacementParams replacementMode.
  • הסרת B נדחית.
  • המשתמש D יתווסף מיד עם חיוב יחסי.
‫A (פריט בסיסי), B א' (פריט בסיסי), ג' כן
  • ההחלפה של A -> A ו-B -> C תלויה במצב ההחלפה שמופיע ב-SubscriptionProductReplacementParams replacementMode בכל ProductDetailsParams.
  • כדי להשאיר את פריט א' ללא שינוי, מגדירים את מצב ההחלפה שלו כ-KEEP_EXISTING.
‫A (פריט בסיס), B, ‏ C D (פריט בסיסי), B, C כן
  • ההחלפה של A->D ו-B->B, C->C תלויה במצב ההחלפה שמופיע ב-SubscriptionProductReplacementParams replacementMode בכל ProductDetailsParams.
  • כדי שהפריטים B ו-C יישארו ללא שינוי, צריך להגדיר את מצב ההחלפה שלהם כ-KEEP_EXISTING.

כשמשתמשים ב-SubscriptionUpdateParams

פריטים קיימים פריטים ששונו האם צריך להגדיר את פרטי ההחלפה? התנהגות
‫A (פריט בסיסי), B ‫A (פריט בסיסי) לא
  • פריט ב' מתוזמן להסרה מושהית.
  • ההתנהגות של פריט א' תלויה בהגדרה שינויים במינוי הבסיסי ובמבצע של המינוי הבסיסי.
  • המחיר של פריט א' מתעדכן למחיר העדכני, ויכול להיות שהמשתמשים יאבדו את התשלומים הראשוניים שקיבלו במהלך ההרשמה, בהתאם לקריטריונים לזכאות להטבה.
A ‫A (פריט בסיסי), B לא
  • פריט ב' נוסף באופן מיידי עם חיוב יחסי.
  • ההתנהגות של פריט א' תלויה בהגדרה שינויים במינוי הבסיסי ובמבצע של המינוי הבסיסי.
  • המחיר של פריט א' מתעדכן למחיר האחרון, ויכול להיות שהמשתמשים יאבדו את התשלומים הראשוניים שקיבלו במהלך ההרשמה, בהתאם לקריטריונים לזכאות להטבה.
‫A (פריט בסיס), B ‫A (פריט בסיסי), C לא
‫A (פריט בסיסי), B B (פריט בסיסי) לא מתוזמנת הסרה מושהית של A.
‫A (פריט בסיסי), B C (פריט בסיסי) כן
‫A (פריט בסיס), B C (פריט בסיסי), B כן ההחלפה של A -> C תלויה ב-setSubscriptionReplacementMode (הוצא משימוש ב-PBL 8.1).
‫A (פריט בסיס), B C (פריט בסיס), D כן
  • ההחלפה של A -> C תלויה ב-setSubscriptionReplacementMode (הוצא משימוש ב-PBL 8.1).
  • הסרת B נדחית.
  • המשתמש D יתווסף מיד עם חיוב יחסי.

התראות בזמן אמת למפתחים

השדה subscriptionId לא מסופק ב-RTDN לרכישות של מינוי עם חבילות, שמכילות כמה זכויות לפריטים. במקום זאת, אפשר להשתמש בממשקי Play Developer API כדי לקבל את הרכישה ולראות את זכויות הפריט המשויכות.

שינויי מחיר למנויים קיימים

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

סיום של קבוצת תמחור קודמת בעלת מאפיינים משותפים

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

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

    דוגמה:

    • נניח שיש לכם מינוי עם חבילות (פריטים א' וב'), שמתחדש ב-7 בכל חודש.
    • מחיר פריט א' עובר שינוי מ-7 $‎ ל-10 $‎, והעלייה במחיר צפויה לחול ב-7 ביולי.
    • העברת מחירים חדשה מ-5 $ל-6 $מתחילה בפריט B ב-2 ביוני. מכיוון שהעלאת מחיר בכפוף להסכמה מתחילה 37 ימים אחרי ההעברה, העלאת המחיר המוקדמת ביותר של פריט ב' תהיה ב-7 באוגוסט.

    בתרחיש הזה, עד שהמשתמש יאשר את שינוי המחיר של פריט א' (עד שהסטטוס שלו יהיה CONFIRMED), שינוי המחיר של פריט ב' לא יירשם ברכישת המינוי הזו, והשיטה SubscriptionPurchaseV2 לא תחזיר פרטים על שינוי המחיר של פריט ב'. אחרי שהמשתמש מאשר את שינוי המחיר של פריט א', מתחיל שינוי המחיר של פריט ב'. המשתמש יקבל את העלאת המחיר בכפוף להסכמה על פריט ב' רק אחרי שיאשר את העלאת המחיר בכפוף להסכמה על פריט א'.

  • האימייל מ-Google Play כולל רשימה של כל הפריטים שהמחירים שלהם עלו או ירדו באותו היום.

ביטול מינוי עם חבילות

המשתמשים יכולים לבטל את הרכישה כולה של מינוי עם חבילות במרכז המינויים של Play, ואתם יכולים לבטל את הרכישה כולה של מינוי עם חבילות רק באמצעות ממשק API של Google Play למפתחים.

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

ביטול מינויים עם חבילות ומתן החזר כספי עליהם

ריכזנו כאן כמה הנחיות לביטול מינויים ולמתן החזרים כספיים:

  • אפשר להשתמש ב-Play Console כדי להנפיק החזר כספי על סכום מסוים עבור הזמנה ספציפית, בלי לבטל את הגישה למינוי.

  • מתקשרים אל orders.refund כדי להחזיר החזר מלא על תשלומים ספציפיים על מינוי שהמשתמש ביצע, בלי לבטל את הגישה למינוי.

  • מתקשרים למספר purchases.subscriptionsv2.revoke כדי לבטל באופן מיידי את הגישה לכל הפריטים במינוי. בעזרת ה-API הזה תוכלו:

    • לבטל את הגישה לכל הפריטים ולספק החזר כספי יחסי.

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

    • לבטל את הגישה לכל הפריטים ולספק החזר כספי מלא.

    • ביטול הגישה לפריט ספציפי עם החזר כספי מלא על הפריט.

ביטול פריט בודד במינוי עם חבילות

כדי לבטל פריטי מינוי בודדים במינוי עם חבילות הרחבה בלי לבטל את הרכישה כולה, צריך להתקשר אל purchases.subscriptionsv2.revoke עם השדה ItemBasedRefund שמוגדר ב-RevocationContext. אפשר להגדיר את productId של הפריט שרוצים לבטל את הגישה אליו ולזכות את המשתמש בשדה ItemBasedRefund.

אפשר להגדיר את השדה ItemBasedRefund לרכישות של פריט אחד או יותר של מינוי עם חידוש אוטומטי.

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

שיקולים

  • כשמשתמשים ב-ItemBasedRefund, אפשר לבטל את הגישה רק לפריט אחד בכל פעם. אפשר להפעיל את הבקשה כמה פעמים אם צריך לבטל כמה פריטים.
  • אם רכישת המינוי נמצאת באחד מהמצבים של דחיית התשלום, או שהפריט שצוין ב-ItemBasedRefund לא נמצא בבעלות או שתוקפו פג, דחיית הפריט נחסמת.
  • אין תמיכה בהשבתת פריט במינוי בתשלום מראש.

דחיית החיוב

אפשר להקדים את תאריך החיוב הבא של מינוי עם חבילות תכונות באמצעות השיטה Purchases.subscriptionsv2:defer.

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

האפשרות הזו יכולה להיות שימושית לקידומי מכירות או למחוות של רצון טוב כלפי לקוחות. אפשר לדחות את החיוב ביום אחד בלבד או עד שנה לכל קריאה ל-API. אפשר לשלוח קריאה ל-API כמה פעמים כדי להאריך את הדחייה לפני תאריך החיוב החדש.

SUBSCRIPTION_DEFERRED התראה בזמן אמת למפתחים מופעלת כשמתבצעת הפעולה הזו.

תוקף הפריט פג במהלך דחיית התשלום

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

לא משנה אילו פריטים נכללים בחידוש, אם התשלום על החידוש נדחה, המינוי כולו ייכנס לתקופת חסד והחשבון יוקפא, כמו שמתואר במסמכים הבאים.

בחירת תקופת השחזור

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

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

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

תקופת חסד

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

השהיית חשבון

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

אם המינוי בהמתנה יחודש, רכישת המינוי תמשיך כרגיל. אם המינוי לא יחודש, תוקף הפריטים שנדחו בגלל בעיה בתשלום יפוג, והגישה לפריטים האחרים תחודש למשך יתרת תקופות החיוב שלהם.

דוגמה:

  • למשתמש יש מינוי My Base Plan שמתחדש ב-1 בכל חודש. ב-15 באוגוסט הוא מוסיף מינוי חבילה בעלות של 10 $לחודש עם תקופת ניסיון בחינם למשך שבעה ימים. לא הוגדרה תקופת חסד לאף אחד מהפריטים, ובשניהם הוגדרה תקופת השהיית חשבון של 30 ימים.

  • ב-22 באוגוסט, המשתמש מחויב ב-2.90 $‎ ‏ (10*9/31) על החלק היחסי עד 31 באוגוסט, אבל אמצעי התשלום של המשתמש פג לפני כן, והמינוי נדחה ב-22 באוגוסט.

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

בדוגמה הקודמת, המינוי נכנס להקפאת החשבון ב-22 באוגוסט.

  • אם החשבון ישוחזר ב-25 באוגוסט, לפני מועד החידוש הכללי ב-1 בספטמבר, המשתמש יקבל גישה מחדש ל-My Base Plan ול-Add on plan באותו היום. תאריך החיוב הבא השתנה ל-4 בספטמבר.

  • אם החשבון לא ישוחזר אחרי 30 יום, המינוי יבוטל ב-21 בספטמבר והמשתמש יאבד את הגישה לתוכנית התוסף, ויחזור לגישה לתוכנית הבסיס שלי עד 30 בספטמבר.

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

דיווח פיננסי והתאמה

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

ללוחות בקרה ב-Play Console:

  • הנתונים הסטטיסטיים של ההכנסות שמוצגים בקטע Financial reporting במסוף מפורטים לפי פריטים.

  • ניהול ההזמנות משקף רכישה של מינוי עם חבילות, ומציג רשימות מפורטות של מה שנרכש. בניהול ההזמנות, אפשר לבטל רכישה של משתמש, לבטל את המינוי שלו או להעניק לו החזר כספי מלא.