The collection and analysis of software license entitlement data in software purchase records is essential to Software Asset Management best practices around compliance analysis and overspend reporting for cost reduction efforts. It is not possible for a software asset manager to complete the full disposition of their duties without comparing software procurement levels to deployment, consumption, and usage of the software. These steps will reveal key data-points like Current License Position (CLP), which is the actual number of licenses purchased after rolling up upgrade rights from previous versions, and Effective License Position (ELP), which is CLP minus those licenses consumed either through deployment or usage.
ELP is a direct measure of software license compliance since it compares purchased entitlements to actual consumption. K2 measures this metric in its “Compliance” report and summarizes it in the Purchasing Dashboard – but only after software purchase records have been entered and correctly reconciled with software management Policies (discussed in “Capturing Software Usage Data“). Once these two data points (Purchases and Policies) are configured, K2 reaches beyond the measurement of ELP and also reports opportunities for optimization and software cost reduction in the “Adjustment” column of the Compliance report. (More on that subject in a future blog.)
Importing Purchase Data
There are essentially two different aspects of data related to software license purchases and subscriptions: transactional data and entitlement data. Each of these data types has a primary and secondary interest to two different groups within your organization. Procurement staff are more interested in transaction data to support the purchasing process: things like cost, quantity, product description, categorization, vendor details, etc. Software Asset Managers are more interested in entitlement data to support consumption measurement that leads to compliance and overspend reporting.
When setting up purchase data in K2 for the first time, it can be helpful to pull data from central procurement records and import it to K2. However, central procurement data is often transaction-centric and so it can require some preparation before importing. Sometimes essential entitlement properties are mixed into product description fields and other times they are just missing entirely and must be collected from other sources, like an invoice, a software license or a contract.
The following notes and related spreadsheet template will help you to prepare purchase data for importing to K2.
Entitlement data includes the licensing rights and conditions that can be measured to identify ‘consumption’ of a software license and determine compliance. Things like license limit, license metric (unit of measure), etc. are all necessary for a successful entitlement reconciliation process. Following is the minimum information necessary to run a reconciliation report.
In order to import purchases, you must start with a CSV (Comma Separated Value) or tab-delimited file. You might already have purchase data in this format, for example from a specific software vendor, or from a software reseller you have used for your software purchases. For certain sources of purchase data, we have already defined field maps to allow easy import into K2. Simply drag and drop the csv file into the Purchases window in KeyConfigure (or select File/Import while the purchases window is in the foreground), a dialog will appear which asks how to complete the import.
Here you will see a list of some predefined “instructions” (field maps) for common purchase data. You can also click “New” to define your own mapping. Finally, if you can arrange for your purchase data to have the standard field names used by K2, you can make a copy of the “Default” Instructions, and being your import (the copy allows you to save mappings from specific Product names in your data to Product records in KeyServer).
Essential Entitlement Data
The following fields constitute the central set of data that you will probably want to record for purchases. If you are using your own format for purchase data, you should include values for each of these fields – but note that the fields in your text file can have any name you want. If you don’t already have a text file, you could use the standard column names below, and then simply use the “Default” instructions instead of setting up your own mapping.
- x-productName – Product name, which will be used to search/map to the appropriate Product during import (if you have it as distinct fields you could also use x-productPublisher and x-productVersion).
- purchaseType – Choice: Software License (“Maintenance” is a type of “Software License”), Media, Tech Support, Other
- purchaseEntitlementType – Choice: Original, Addendum, Upgrade, Exchange
- purchaseMetric – Choice: Site, Node (Device), Concurrent, User, Lease, PVU, Core, Socket (CPU), Special, Custom
- purchaseStartDate – If not perpetual.
- purchaseEndDate – If not perpetual (i.e. this is a “subscription”).
- purchaseRenewDate – The date until which upgrade rights are included for this purchase. Generally for a Subscription, this will match the purchaseEndDate.
- purchaseQuantity – Number of licenses.
Note that “subscription” is not a license “metric” but it is a limiting condition that can be applied to any metric. Thus, it is identified by an End Date on the entitlement itself. Similarly, the Renew Date does not impact the entitlement, but it affects only the upgrade rights that typically accompany a maintenance agreement.
Although none of the above fields are “required” to create a record, they all provide essential information for product identification and entitlement quantification – all are necessary for successful reconciliation.
Understanding Entitlement Type
Entitlement Type includes choices for some subtle but important differences. An “Original” Entitlement generally represents the first time a software product license was purchased or a subsequent purchase made that is not an upgrade, addendum, or exchange for a previous purchase. An “Addendum” modifies the entitlement rights originally granted by another purchase. For example it could extend a subscription (which can also include new version rights). An “Upgrade” grants rights to a newer version (while often also extending “downgrade” rights to continue using the older version). And an “Exchange” grants entitlement to a product in exchange for licensing for another (possibly competitive) product.
How to enter “Maintenance” purchases
If you purchase perpetual entitlements you will often purchase “Maintenance” separately – which would give you access to free upgrades for some period of time. A Maintenance purchase should have a purchaseType of “Software License” and a purchaseEntitlementType of “Addendum”. Finally, a Maintenance purchase would have a purchaseRenewDate (the date until which you get free upgrades) but no purchaseStartDate or purchaseEndDate (since the entitlements themselves would be granted by a different purchase).
Additional useful columns
Presence of this data will further enhance reconciliation, compliance, and optimization reports.
- orderDate – The date of this PO.
- purchaseOrderID – PO numbers must be unique unless they represent multiple items on a single PO.
- purchaseItemNumber – multiple items can appear on a single PO and this value specifies which row the entry is for. If you do not map a value to this field, item numbers will be assigned sequentially – but in that case note that importing the same file twice will create duplicate entries.
- purchaseUnitPrice – the price paid for each license entitlement.
- purchaseExtendedCost – Unnecessary if Unit Price is available.
Synthetic Software Purchase Records
A complete historical record of software purchases, upgrades, subscriptions, etc. will provide the basis for K2 to compute CLP for each product, but it may be impractical and unnecessary to enter or import the entire historical record. Synthetic purchase records in K2 can be used to create baselines for calculating CLP when going forward with new purchases. For synthetic records, you can invent your own PO# – or leave the field blank and let the import make up a value. Be sure to either attach or identify the location of documentation that demonstrates “proof of entitlement”.
Even More Columns and Attachments
There are many other columns which are not essential to the calculation of CLP but are self explanatory. But two in particular that are useful in demonstrating proof of entitlement are the Documents field (for attaching invoices, contracts, etc.) and the serialNumbers column. You can not import to the Documents field but you can add documents to the record after it has been created (either by import or by manual entry). If you need to import multiple serial numbers/install codes, be sure to separate them with commas (and if you’re working with a CSV, the group of serial numbers should then be surrounded by quotes so that it still gets treated as a single field). For a complete list of columns you can refer to the documentation on KSPurchaseItems and KSPurchaseOrders.
Additional tips for importing software purchase records to K2.
- When working with the Import Instructions Field Map, the source data field names don’t have to match the field names in K2.
- Be sure to set purchaseQuantity to “1” for Site licenses. The opposing rule to this is that if the quantity is greater than one, it is not a “site license”. Thus, you should select another appropriate metric.
- There is no need to import the “purchaseName” as K2 will create a name for the purchase record when the product has been added to it (after the import). Instead, put the publisher and product name as the leading item in the “purchaseDescription” field. This will help you to identify the associated product after the import to easily match up Purchases with Products.
- Don’t import a value for extended cost unless there is no specific unit cost. Extended cost is a calculated value unless a fixed value has been entered.
- License packs are uncommon, so the “purchaseEntitlementsPerPackage” value is usually NULL. Most records will only use the purchaseQuantity value.
- Download the purchase import spreadsheet template here: purchase-import-template-2018
Final steps, post-import
After the import completes, there are three additional steps you should take. We will cover this in more depth in another post, but briefly… First, make sure each Purchase has an associated Product. You will be prompted to select products during import, but might find cases where a new Product needs to be defined. Second, use Reconcile to make sure that Addendum and Upgrade purchases have support from prior purchases. Third, create Policies from each Purchase (again using Reconcile).
Finally, you can learn more about importing Purchase records in the documentation: http://www.sassafras.com/hrl/7.4/purchases.html#import