ALSO Marketplace

Reads the ALSO Cloud Marketplace (SimpleAPI) and provides the booked subscriptions per end customer — the purchasing side of our CSP business.

Credentials (gear icon)

Field	Meaning
API URL	https://marketplace.also.de
Username / password	ALSO Marketplace account with API access
Root account ID	AccountId of your own partner account under which the end-customer companies live

The connection test fetches the company list below the root account ID.

Metrics

• One product = one metric, named as in the Marketplace. Identical products with different billing modes are tracked separately. Two signals in the ALSO BillingType are decisive: the commitment ((with 1-year commitment) = annual subscription) and the payment mode taken from the wording — Prepaid/"Vorauszahlung" = annual payment, Monthly/Charge in advance = monthly payment. The - P1M/- P1Y suffix is not interpreted as the payment mode (depending on the vocabulary it means either the payment OR the commitment period):
  • Monthly (with 1-month commitment) - P1M → "… (monatlich)" — monthly subscription, monthly payment
  • … (with 1-year commitment) - P1M or Monthly (with 1-year commitment) - P1Y → "… (jährlich, monatliche Zahlung)" — annual commitment but paid monthly; this also applies to the - P1Y variant whose wording is "Monthly" (the P1Y suffix here is the commitment period). Lands on the monthly invoice by default
  • Prepaid (with 1-year commitment) - P1Y → "… (jährlich)" — annual prepayment; in the weclapp mapping it defaults to the annual invoice (monthly would make no sense for a prepayment; you can switch at any time, invoicing only happens once the anchor month is set). In the display (detail view, weclapp mapping, CSV columns) these rows appear as "… (jährlich, Prepaid)" — the metric itself remains "… (jährlich)"
• Billing cycle on the product name: In the detail view, every product name carries the cycle as a suffix — "… (monatlich)", "… (jährlich, Prepaid)" or "… (jährlich, monatliche Zahlung)". Same-named subscriptions with different billing are thus distinguishable at a glance, and prepaid annual subscriptions can be found (also in the weclapp article mapping) by searching for "prepaid". The "Prepaid" suffix is display-only: the underlying metric is still called "… (jährlich)" — it is the key of the article mappings and the snapshot history and stays stable. In the snapshot state the cycle comes directly from the billing metric (see above, identical to the weclapp billing), in the live view from the ALSO BillingType.
• Price protection & term: A customer's detail view shows "Price protection until" and "Term end" per subscription (where ALSO provides them, typically for NCE term commitments). Expired price protection is marked red, expiry within 60 days yellow — that is where new purchase conditions are due next. The same hint appears in the weclapp article mapping on every ALSO service row directly below the sales price (from the stored snapshot state, hence without any waiting time).
• Configuring renewals (e.g. aligning to the calendar month): In the detail view, the clock icon on each subscription opens the renewal dialog — it loads the renewal fields live from the Marketplace and renders them as there: select fields (e.g. "Billing Type") with the readable ALSO options, required fields with *, number fields as numeric inputs, ALSO hints below the field. For "Subscription end date alignment", Multiverse computes the "end of calendar month" alignment itself from the subscription's term end and offers it as a preselected, editable option — scattered term ends thus converge on the same cut-off date, regardless of whether ALSO exposes the option list server-to-server (in the end the value is just a date that is written along directly). The current term end is shown in the dialog for reference. Additional alignment targets (cotermination onto another subscription) are loaded live from ALSO on top (ResolveRemoteEnum) where available; otherwise the computed date or a free entry remains usable. Writes happen only after an explicit confirmation step, each license individually; "Reset to default" removes the configuration again. Subscriptions with a stored renewal configuration carry the "configured" chip; every write operation lands in the audit log.
• Azure: Each Azure subscription remains its own row (Azure Plan … › Subscription-Name), valued with the consumption of the last snapshot day. Implausible outlier values are discarded.
• Adobe products are counted via the license quantity, all others via the booked unit count.

Price list (purchase prices)

The real purchase price comes from the subscription itself: the ALSO subscription data carries the actual monthly purchase price per subscription including price protection — i.e. exactly the price ALSO really charges. The snapshot stores it per subscription; it is the master for margin calculation and the purchase-price comparison in Controlling.

The price list is the fallback and reference value for it: the Excel export "Prices" from the ALSO Marketplace (price-list download in the portal). An upload card sits at the top of the ALSO view for this: simply drag in or click and select the .xlsx file.

• Every upload replaces the stored list completely — just upload the current export regularly (e.g. after ALSO price changes).
• The card shows the state of the last upload (date, rows, services).
• The purchase prices take effect from the next ALSO snapshot: the snapshot adopts the subscription purchase price per subscription; only where ALSO does not provide one does it resolve the list purchase price via service and billing variant (PROMO variants remain strictly separate).
• Controlling uses this ALSO purchase price as the cost basis for ALSO line items and reports deviations from the weclapp purchase price. Since the subscription purchase price already includes price protection, the same article can carry different purchase prices per customer — the price protection is shown right next to it in Controlling.

Specifics

• Departments: If a company has departments (the marketplace COMPANY STRUCTURE view), they are tracked as separate customers. The snapshot reads the account tree of each company via the marketplace's internal GetAccountTree call — the public SimpleAPI does not expose departments — and assigns every subscription to its department (product accounts may nest, e.g. Azure Plan children). Department quantities therefore leave the parent company exactly; a department that belongs with its company can simply be merged into it, and irrelevant department tenants can be hidden. If the tree lookup fails, the company temporarily collects everything again and the server log names the reason (ALSO: account-tree lookup …).
• Microsoft IDs: For CSP products, ALSO also reads the Microsoft tenant ID and the license ID (skuId) — the basis for the ID-based ALSO↔Microsoft comparison.
• Dashboard totals exclude Azure consumption and "Extra File Storage" so that seat counts are not distorted.

View

Customer list (snapshot state, date toggle) — clicking a customer opens the detail view instantly from the subscription master data stored during the nightly snapshot: products with quantities, price-protection indicators, term ends and renewal buttons, without any live fetch. A chip shows the state ("As of: …"); "Refresh live" fetches exactly this customer fresh from ALSO (after a renewal write this happens automatically). The live toggle of the customer list remains for the special case of loading the complete company list fresh from the Marketplace.