Sizing Guide Sales Solutions by Vistex 3.0

Sizing Guide Public
Document Version: 3.0 – Final

Date: October 4, 2022
Sizing Guide
Sales Solutions by Vistex
Application Help PUBLIC
Table of Contents
1 About This Guide........................................................................................................................ 3

1.1 Introduction ........................................................................................................................................................ 3
1.2 Purpose ............................................................................................................................................................. 3
2 Database Consumption ............................................................................................................... 5

2.1 Master Data ....................................................................................................................................................... 6
2.1.1 Functionality....................................................................................................................................... 6
2.1.2 Size Calculation ................................................................................................................................. 6
2.2 SAP® Extended Price Management by Vistex .................................................................................................. 7
2.2.1 Functionality....................................................................................................................................... 7
2.2.2 Data Storage...................................................................................................................................... 7
2.3 SAP® Channel Program Management by Vistex .............................................................................................. 8
2.3.1 Functionality....................................................................................................................................... 8
2.3.2 Data Storage...................................................................................................................................... 8
2.4 SAP® Vendor Program Management by Vistex .............................................................................................. 10
2.4.1 Functionality..................................................................................................................................... 10
2.4.2 Data Storage.................................................................................................................................... 10
2.4.3 Size Calculation ............................................................................................................................... 10
2.5 SAP® Rights and Royalty Management by Vistex, cloud edition .................................................................... 12
2.5.1 Functionality..................................................................................................................................... 12
2.5.2 Data Storage.................................................................................................................................... 12
2.5.3 Size Calculation ............................................................................................................................... 12
2.6 Factors that Influence Database Consumption ................................................................................................ 15
3 Miscellaneous .......................................................................................................................... 16
3.1 Additional Information ...................................................................................................................................... 16
3.2 Comments and Feedback................................................................................................................................ 16
4 Glossary ................................................................................................................................. 17
October 4, 2022
Sizing Guide – Version: 3.0 – Final © 2022 Vistex, Inc. All rights reserved.
Sales Solutions by Vistex 2
1 About This Guide
1.1 Introduction
Sales Solutions by Vistex is a suite of applications that are individually licensed and can be used independently or
collaboratively to plan, execute, administer, and account for promotional pricing, rebates, reimbursements, and other
incentives.
The Sales Solutions by Vistex suite has the following individually licensed applications:
• SAP® Extended Price Management by Vistex

• SAP® Channel Program Management by Vistex
• SAP® Vendor Program Management by Vistex
• SAP® Rights and Royalty Management by Vistex, cloud edition
This suite of applications is deployed on the SAP Business Technology Platform (BTP). Knowledge of BTP is not
required to determine the database size of the solution suite deployment. However, if more information on BTP and
any of its services or functions referenced in this guide are desired, the reader may study documentation available for
BTP found at https://help.sap.com/viewer/p/BTP. You can also search the SAP Help Portal for “SAP Business
Technology Platform”.
All sizing calculations in this guide assume an SAP HANA database is used to store data. SAP BTP applications use
SAP HANA for persistence, and this database is the only offering.
1.2 Purpose
Because the license fee for the suite’s applications can vary based on the amount of database storage consumed by
the customer, the customer should be able to predict his database consumption and determine any additional license
fees that may be owed as a result of exceeding the normal allotment of database storage.
This guide was created to allow persons implementing or responsible for the application suite to predict the database
consumption based on a number of metrics.
Suite applications are not licensed based on hardware resource consumption (except database storage), so the number
of servers, size of server memory and other hardware metrics (other than database storage) are not addressed in this
sizing guide.
This guide is NOT intended to advise Vistex, host or hyperscaler staff on the size of hardware, the number of tenants
per instance or any other deployment consideration of the suite software.
This guide addresses the following target audience:

• Customer & Vistex system administrators
• Vistex technical consultants
October 4, 2022
2 Database Consumption
Each application in the solution suite is designed to support different business processes for different company areas
or roles in the supply chain. While each application has unique capabilities and data structures, most of the
applications (SAP Extended Price Management is the significant exception) have similar architecture and database
consumption behaviors.
In this section, the data design of each application is described, and the data consumption methodology of each is
provided.
October 4, 2022
2.1 Master Data
2.1.1 Functionality
Each application in the solution suite leverages a common set of master data, including business partner and product
master data. Business partner and product master data is held in a central repository within the solution suite and
can be re-used in any suite application. Some master data might only be relevant for a single application. When
counting master data, be sure that each unique business partner or product is only counted once, regardless of the
number of suite applications that use the record.
Other common meta data is also stored, but the contribution of such data to overall database size is negligible.
2.1.2 Size Calculation
The record size for business partners or products is an amalgamation of several records and assumes a typical
number of attributes (identifiers, addresses, units of measure, characteristics, etc.). Since the overall size of a
complete business partner or product specification is small, the variation in the number of attributes and their
summed size contributes negligibly toward total database consumption; therefore, the attributes are not counted and
measured individually in this guide.
See the Master Data tabs in each of the worksheets found throughout this document.
October 4, 2022
2.2 SAP® Extended Price Management by Vistex
2.2.1 Functionality
SAP Extended Price Management solution creates and maintains price records for use by this suite of applications as
well as SAP S/4HANA. Extended Price Management can read condition records from SAP S/4HANA as well as
publish these—as well as new—condition records to S/4HANA. Extended Price Management is used to maintain
S/4HANA condition records with greater efficiency than the native features of S/4HANA. Price records maintained by
Extended Price Management can include list prices, customer-specific prices, raw material and commodity prices,
and kit/bundle/bill of material pricing.
2.2.2 Data Storage
SAP Extended Price Management leverages the common master data in the solution suite, including business
partner and product master data. Aside from master data, the number of prices (of any type) is the principal driver of
database size.
Whenever a price changes over time, a new record for the new price is created. The existing record for the previous
price is modified to include a termination date prior to the new record’s effective date. Therefore, each price change
results in an additional price record.
Obsolete prices are maintained in their original price record with an effective date range so that older transactions
can be priced with historical accuracy and an audit trail can be maintained.
The actual price is never modified in a price record unless the price was invalid and corrected to resolve a pricing
error.
First, determine the number of pricing records—both for purchased as well as sold products. Then multiply the total
number of price records by the price record size to determine the total database consumption for all price records.
Use the “Vistex GTMS Extended Price Management Sizing” spreadsheet to determine the database storage
requirements.
October 4, 2022
2.3 SAP® Channel Program Management by Vistex
2.3.1 Functionality
SAP Channel Program Management application defines offers to customers or channel partners. These offers
include agreements for price discounts, rebates and reimbursements for valid expenses. Channel Program
Management evaluates sales data—obtained from either an ERP system or from claims or reports submitted by
channel partners—to determine eligibility for channel program benefits. The application can use the transaction data
to accrue for eventual expenses as well as determine the final payment when all necessary data is available and final
calculations are made at the time payment is due. Accruals and settlements are posted to ERP financial accounts.
2.3.2 Data Storage
Channel Program Management leverages the common master data in the solution suite, including business partner
and product master data. Channel programs are defined in agreements that contain eligibility rules, calculation
formulas and benefit parameters. The price discounts are recorded as price records, and the rebates and
reimbursements are often based on sales data obtained from an ERP system or from transaction files submitted from
channel partners.
Submitted claims for reimbursement have both accrual and settlement amounts calculated at the line item, whereas
rebate accrual and settlement amounts are generally calculated in aggregate for the program and period.
Channel Program Management is comprised of several objects: agreements, claims, buckets and postings. Each
object must be sized independently and then added to the other objects’ consumption to determine the overall
contribution to database size.
Another consideration in database consumption is the amount of data that will be retained each year. For total
database growth, the annual database consumption should be multiplied by the number of years of data retention.
Individual company policies should determine how long data should be retained for financial audit, data analysis, data
privacy protection, storage cost containment and other reasons.
Agreements may be effective for one year or last for several years. An agreement may be extended or renewed, or
may be reimplemented based on a renegotiation. New agreements may be added as business increases with new
partners or additional promotional strategies with existing partners. The number of agreements introduced in a single
year should be quantified. This number should be multiplied by the number of years that those agreements will be
retained, without regard to the number of renewals of an existing agreement or consideration of multi-year
agreements.
October 4, 2022
Claims are received periodically from many partners. Although the set of partners submitting claims is fairly
consistent period-to-period, the number of line items within each partner’s claim can vary period-to-period as
business activity fluctuates. An annual average of claim line items, either by partner then summed across partners or
across all claims in aggregate (regardless of partner), should be used to determine an annual database consumption
rate.
A single claim line item can spawn other database records. An accrual for the calculated amount may be generated
before the claim line item is settled, and disputes and negotiations can give rise to reconciliation records related to
the original claim line item. For these reasons, the actual claim lines are multiplied by a factor to approximate the
actual number of records created for, and related to, claim lines.
Note: The size of the claim header is negligible compared to the size and number of the claim lines, and therefore is
not counted.
Buckets are used to store transaction lines and calculation amounts. The number of buckets is based on partner and
period, but the number of bucket lines correlates to the number of transactions and their multiplication for multiple
agreements.
Transactions considered for buckets include claim lines as well as sales orders, purchase orders, point-of-sale or
utilization reports, and other transactions interfaced or imported from external systems. It is possible that a
transaction line item can spawn more than one database record if the line is applicable to more than one agreement.
In addition to replicated transaction lines for multiple agreements, there can be multiple records created to account for
an accrual and settlement calculation related to the transaction line. For all of these reasons, the actual transaction
lines are multiplied by a factor to approximate the actual number of records created for, and related to, transaction
lines.
Note: The size of the bucket definition is negligible compared to the size and number of the bucket transaction lines,
and therefore is not counted.
Posting records contain the calculated amounts for accruals or settlements as well as the account information for the
posting destination. Posting records do not generally aggregate data, so the number of bucket lines corresponds to
the number of posting records. This facilitates a full audit trail from the account posting to the originating transaction.
Note: The number of posting records in a posting document can vary widely based on business activity and
accounting periods. The size of the posting document definition is negligible compared to the size and number of the
posting records, and therefore is not counted.
Use the “Vistex GTMS Channel Program Management Sizing” spreadsheet to determine the database storage
requirements.
October 4, 2022
2.4 SAP® Vendor Program Management by Vistex
2.4.1 Functionality
SAP Vendor Program Management application defines offers by suppliers to manufacturer purchasing departments,
wholesale distributors, re-distributors and retailers. These offers include agreements for price discounts, rebates and
reimbursements for valid expenses. Vendor Program Management evaluates purchase data —typically obtained
from an ERP system—to determine eligibility for supplier program benefits. The application can use the transaction
data to accrue for eventual reimbursements and revenues as well as determine the final payment when all necessary
data is available and final calculations are made at the time payment is due. The application can generate a claim for
these payments, when necessary, and process any adjustments or negotiated settlements of a claim. Accruals and
settlements are posted to ERP financial accounts.
2.4.2 Data Storage
Vendor Program Management leverages the common master data in the solution suite, including business partner
and product master data. Channel programs are defined in agreements that contain eligibility rules, calculation
formulas and benefit parameters. The price discounts are recorded as price records, and the rebates and
reimbursements are often based on either inventory purchases (“sell-in”) or sales (“sell-out”) data obtained from an
ERP system.
Claims generated for reimbursements have both accrual and settlement amounts calculated at the line item, whereas
rebate accrual and settlement amounts are generally calculated in aggregate for the program and period.
Vendor Program Management is comprised of several objects: agreements, claims, buckets and postings. Each
partners or additional promotional strategies with existing partners. The number of agreements introduced in a single
year should be quantified. This number should be multiplied by the number of years that those agreements will be
October 4, 2022
retained, without regard to the number of renewals of an existing agreement or consideration of multi-year
agreements.
Claims are generated periodically and sent to suppliers. Although the set of suppliers that will receive the claims is
fairly consistent period-to-period, the number of line items within each claim to a supplier can vary period-to-period as
business activity fluctuates. An annual average of claim line items, either by supplier then summed across suppliers
or across all claims in aggregate regardless of supplier, should be used to determine an annual database
consumption rate.
A single claim line item can spawn other database records. An accrual for the calculated amount may be generated
before the claim line item is settled, and disputes and negotiations can give rise to reconciliation records related to
the original claim line item. For these reasons, the actual claim lines are multiplied by a factor to approximate the
actual number of records created for, and related to, claim lines.
Note: The size of the claim header is negligible compared to the size and number of the claim lines, and therefore is
not counted.
Buckets are used to store transaction lines and calculation amounts. The number of buckets is based on partner and
period, but the number of bucket lines correlates to the number of transactions and their multiplication for multiple
agreements.
Transactions considered for buckets include claim lines as well as sales orders, purchase orders, and other
transactions interfaced or imported from external systems. It is possible that a transaction line item can spawn more
than one database record if the line is applicable to more than one agreement.
In addition to replicated transaction lines for multiple agreements, there can be multiple records created to account for
an accrual and settlement calculation related to the transaction line. For all of these reasons, the actual transaction
lines are multiplied by a factor to approximate the actual number of records created for, and related to, transaction
lines.
Use the “Vistex GTMS Vendor Program Management Sizing” spreadsheet to determine the database storage
requirements.
October 4, 2022
2.5 SAP® Rights and Royalty Management by Vistex,

cloud edition
2.5.1 Functionality
SAP Rights & Royalty Management application defines intellectual properties associated with materials and various
offers of combinations of materials and rights. The products sold in royalty programs are these combinations of
materials and allowed rights. The royalty programs are offered by the owners of the intellectual property (“licensors”)
to manufacturers of consumer products; media producers, distributors or broadcasters; and other companies that
want to license the use of the intellectual property for their own purposes (“licensees”). The royalty is the payment
made by the licensee to the licensor for the right (or license) to use the intellectual property for the mutually agreed
purpose(s).
The licensee is obligated to periodically report how the intellectual property has been used and to make royalty
payments according to this usage and the royalty agreement terms. The application uses the royalty report to
calculate the royalties owed and make this amount to the royalty payment received to validate the licensee’s royalty
calculations. The licensee may be required to make an advance royalty payment or minimum royalty payments
regardless of usage. Any pre-payment credits are considered by the solution in determining the royalty payment
necessary for each period based on actual usage or obligated minimum amounts.
Pre-payments and calculated royalty settlements are posted to ERP financial accounts.
2.5.2 Data Storage
Rights & Royalty Management leverages the common master data in the solution suite, including business partner
and product master data. Royalty programs are defined in agreements that contain rights sets, eligibility rules,
calculation formulas and royalty rates. A licensee can generate a royalty payment and report from the sales order
information found in an ERP system. A licensor, however, has no data in an ERP system that represents the sale of
licenses nor the licensee’s usage; instead, the royalty report submitted by the licensee is used to drive the royalty
payment calculation and validation process for a licensor.
A royalty report submitted with a royalty payment contains line items giving details of each use of an intellectual
property that can include usage quantities, description of subsequent usage (licensee’s products, markets, etc.) and
the royalty amount due on each report line item.
Rights & Royalty Management is comprised of several objects: agreements, reports, buckets and postings. Each
October 4, 2022
partners or from the expansion of intellectual properties available and the scope of rights available (more sales
channels, markets or new uses). The number of agreements introduced in a single year should be quantified. This
number should be multiplied by the number of years that those agreements will be retained, without regard to the
number of renewals of an existing agreement or consideration of multi-year agreements.
Royalty report line items are determined from the licensee’s sales orders, purchase orders, and other transactions
interfaced or imported from external systems. For a licensor, only the royalty report line items submitted by a
licensee are considered. It is possible that a report line item can spawn more than one database record if the line is
applicable to more than one agreement or requires payment to more than one party.
Royalty reports are generated periodically and sent to the owner of the intellectual properties (licensor). Although the
set of licensors that will receive the royalty reports can be fairly consistent period-to-period, the number of line items
within each report can vary as business activity fluctuates. An annual average of royalty report line items, either by
licensor then summed across licensors or across all royalties in aggregate regardless of licensor, should be used to
determine an annual database consumption rate.
Note: The size of the royalty report header is negligible compared to the size and number of the report’s lines, and
therefore is not counted.
Buckets are used to store transaction lines and calculation amounts. The number of buckets is based on license
partner and period, but the number of bucket lines correlates to the number of transactions and their multiplication for
multiple agreements.
A single royalty report line item can spawn other database records. A song or film, for example, can generate a
royalty to the artist/actor, the composer/writer, the producer, etc. Each royalty payment requires its own database
record, resulting in a one-to-many relationship between the reported line item and the number of
calculations/payments arising from the usage indicated in that reported line item. Generally, there is no line-item
level accruals for royalties because the licensor is not aware of the usage of the intellectual property until the licensee
sends a royalty report. However, there might be some accruals as well as some disputes, negotiations and
resubmissions causing an increased number of database records. For these reasons, the actual royalty report and
subsequent bucket (calculation) lines can be multiplied by a factor to approximate the actual number of records
created for, and related to, royalty report lines.
October 4, 2022
Use the “Vistex GTMS Rights and Royalty Management Sizing” spreadsheet to determine the database storage
requirements.
October 4, 2022
2.6 Factors that Influence Database Consumption
Master and meta data related to transaction processing, such as the agreements, rights set items, bucket definitions,
and royalty reporting do not significantly affect overall storage consumption. For example, a company may have
hundreds or even a few thousands of agreements, but it will process many millions of transactions for those
agreements, such that the consumption by transactions overshadows the consumption by meta or master data.
A key factor in determining the size of a royalty agreement is the permutation of possible rights for any intellectual
property. The rights can be any combination of any number of sets (dimensions in licensing). Examples of sets are
territory (geographical hierarchy), end-use format (e.g. for media this could be TV broadcast, online streaming, DVD
rental, etc. but for high tech this could be different device families like smart phone versus laptop), language, etc. As
the number of sets (or dimensions), or the number of options within a set, increases, the possible combinations of set
values (and thus the number of unique rights) increases exponentially. Every right available might be assigned or
used in an agreement.
The number of rights available or assigned in any agreement can vary widely and be difficult to predict
during the sizing exercise!
October 4, 2022
3 Miscellaneous
3.1 Additional Information
For Additional information on Sales Solutions by Vistex applications (branded by Vistex as the Go-to-Market Suite®
or GTMS®), please refer to the following sources:
▪ Online Help: http://help.vistex.com
3.2 Comments and Feedback
Your comments and feedback are very welcome; please send them to support@vistex.com.
October 4, 2022
4 Glossary
Term Definition
GTMS® Go-to-Market Suite by Vistex, the official Vistex branding for the “Sales Solutions by
or Go-to-Market Suite® Vistex” suite offered by SAP
BTP SAP Business Technology Platform (formerly SAP Cloud Platform) – the platform-as-
a-service used to offer the applications in Sales Solutions by Vistex
October 4, 2022

Sizing Guide Sales Solutions by Vistex 3.0

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sizing Guide Sales Solutions by Vistex 3.0

Uploaded by

Copyright:

Available Formats

Sizing Guide Public

Document Version: 3.0 – Final

1 About This Guide........................................................................................................................ 3

2 Database Consumption ............................................................................................................... 5

• SAP® Extended Price Management by Vistex

This guide addresses the following target audience:

2.1 Master Data

2.1.2 Size Calculation

2.2 SAP® Extended Price Management by Vistex

2.2.2 Data Storage

2.2.3 Size Calculation

2.3 SAP® Channel Program Management by Vistex

2.3.2 Data Storage

2.3.3 Size Calculation

2.4 SAP® Vendor Program Management by Vistex

2.4.2 Data Storage

2.4.3 Size Calculation

2.5 SAP® Rights and Royalty Management by Vistex,

2.5.2 Data Storage

2.5.3 Size Calculation

2.6 Factors that Influence Database Consumption

3.1 Additional Information

3.2 Comments and Feedback

You might also like